Displaying 9 results from an estimated 9 matches for "btrfs_setattr".
2007 Jun 29
2
Mknod: Operation not permitted
When trying to move my root to a btrfs filesystem, I found a missing
feature (or a bug). It's not possible to create device files. To
reproduce, run this on a btrfs filesystem:
mknod test c 1 1
result:
mknod: `test': Operation not permitted
Frank
2013 Nov 19
6
[PATCH] Btrfs: fix very slow inode eviction and fs unmount
...>
---
fs/btrfs/inode.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 84 insertions(+), 14 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 5a5de36..e889779 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4488,6 +4488,62 @@ static int btrfs_setattr(struct dentry *dentry, struct iattr *attr)
return err;
}
+/*
+ * While truncating the inode pages during eviction, we get the VFS calling
+ * btrfs_invalidatepage() against each page of the inode. This is slow because
+ * the calls to btrfs_invalidatepage() result in a huge amount of calls to...
2014 Aug 05
0
Stack dumps in use_block_rsv while rebalancing ("block rsv returned -28")
...+0x27/0x80
[376007.682117] [<ffffffffa00f18d9>] start_transaction+0x29/0x30 [btrfs]
[376007.682125] [<ffffffffa00f19a7>] btrfs_join_transaction+0x17/0x20 [btrfs]
[376007.682133] [<ffffffffa00f7fa8>] btrfs_dirty_inode+0x58/0xe0 [btrfs]
[376007.682141] [<ffffffffa00fcaf2>] btrfs_setattr+0xa2/0xf0 [btrfs]
[376007.682144] [<ffffffff811eec74>] notify_change+0x1c4/0x3b0
[376007.682146] [<ffffffff811dde96>] ? final_putname+0x26/0x50
[376007.682149] [<ffffffff811d088d>] chown_common+0x16d/0x1a0
[376007.682153] [<ffffffff811f2b08>] ? __mnt_want_write+0x58/0x70...
2010 Nov 19
1
Btrfs_truncate ?
...00000000000000
[69003.807987] Call Trace:
[69003.807987] [<ffffffff810ea526>] ? virt_to_head_page+0x9/0x2d
[69003.807987] [<ffffffff810ce78a>] ? unmap_mapping_range+0x59/0xf5
[69003.807987] [<ffffffff810be8f1>] ? vmtruncate+0x36/0x41
[69003.807987] [<ffffffffa0152718>] ? btrfs_setattr+0x1d5/0x230 [btrfs]
[69003.807987] [<ffffffff8104b2b6>] ? current_fs_time+0x1e/0x24
[69003.807987] [<ffffffff811055e5>] ? notify_change+0x195/0x27e
[69003.807987] [<ffffffff810f1f4a>] ? do_truncate+0x68/0x86
[69003.807987] [<ffffffff810fa6a4>] ? get_write_access+0x10/0x3...
2007 Dec 07
1
Oops
...:38 revo [<b01cd4c5>] btrfs_update_inode+0x45/0xc0
Dec 7 19:18:38 revo [<b01cf329>] btrfs_dirty_inode+0x49/0x80
Dec 7 19:18:38 revo [<b019e950>] __mark_inode_dirty+0x30/0x180
Dec 7 19:18:38 revo [<b0196197>] inode_setattr+0xb7/0x180
Dec 7 19:18:38 revo [<b01cee9e>] btrfs_setattr+0x3e/0x2a0
Dec 7 19:18:38 revo [<b01712e2>] handle_mm_fault+0xf2/0x570
Dec 7 19:18:38 revo [<b019633c>] notify_change+0xdc/0x2c0
Dec 7 19:18:38 revo [<b01a1611>] do_utimes+0x161/0x250
Dec 7 19:18:38 revo [<b01712e2>] handle_mm_fault+0xf2/0x570
Dec 7 19:18:38 revo [<b...
2012 Apr 20
44
Ceph on btrfs 3.4rc
After running ceph on XFS for some time, I decided to try btrfs again.
Performance with the current "for-linux-min" branch and big metadata
is much better. The only problem (?) I''m still seeing is a warning
that seems to occur from time to time:
[87703.784552] ------------[ cut here ]------------
[87703.789759] WARNING: at fs/btrfs/inode.c:2103
2011 Nov 09
12
WARNING: at fs/btrfs/inode.c:2198 btrfs_orphan_commit_root+0xa8/0xc0
Hello,
I''m seeing a lot of warnings in dmesg with a BTRFS filesystem. I''m using
the 3.1 kernel, I found a patch for these warnings (
http://marc.info/?l=linux-btrfs&m=131547325515336&w=2)
<http://marc.info/?l=linux-btrfs&m=131547325515336&w=2>, but that patch
has already been included in 3.1. Are there any other patches I can try?
I''m using
2011 May 05
12
Having parent transid verify failed
...40
May 5 14:17:14 mail kernel: [13680.752117] [<ffffffffa08618cf>]
start_transaction+0xdf/0x270 [btrfs]
May 5 14:17:14 mail kernel: [13680.752123] [<ffffffffa0861d9e>]
btrfs_start_transaction+0xe/0x10 [btrfs]
May 5 14:17:14 mail kernel: [13680.752130] [<ffffffffa086aa6b>]
btrfs_setattr+0x10b/0x2b0 [btrfs]
May 5 14:17:14 mail kernel: [13680.752133] [<ffffffff81159a91>]
notify_change+0x181/0x350
May 5 14:17:14 mail kernel: [13680.752136] [<ffffffff8113dd46>]
do_truncate+0x56/0x90
May 5 14:17:14 mail kernel: [13680.752138] [<ffffffff8114dde0>]
finish_open+...
2012 Dec 13
22
[PATCH] Btrfs: fix a deadlock on chunk mutex
An user reported that he has hit an annoying deadlock while playing with
ceph based on btrfs.
Current updating device tree requires space from METADATA chunk,
so we -may- need to do a recursive chunk allocation when adding/updating
dev extent, that is where the deadlock comes from.
If we use SYSTEM metadata to update device tree, we can avoid the recursive
stuff.
Reported-by: Jim Schutt