similar to: [RFC][PATCH 2/2] Btrfs: implement unlocked dio write

i_alloc_sem has always been a bit of an odd "lock". It''s the only remaining rw_semaphore that can be released by a different thread than the one that locked it, and it''s use case in the core direct I/O code is more like a counter given that the writers already have external serialization. This series removes it in favour of a simpler counter scheme, thus getting rid

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

V1->V2: Check to see if our current ppos is >= i_size after a short DIO read, just in case it was actually a short read and we need to just return. This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the rest via buffered IO. BTRFS needs this because if we encounter a compressed or

Hi all - The following 9 patches add more error handling to the btrfs code: - Add btrfs_panic - Catch locking failures in {set,clear}_extent_bit - Push up set_extent_bit errors to callers - Push up lock_extent errors to callers - Push up clear_extent_bit errors to callers - Push up unlock_extent errors to callers - Make pin_down_extent return void - Push up btrfs_pin_extent errors to

Hello, some time ago we discussed on #btrfs that the nocow attribute for files wasn''t working (around 3.3 or 3.4 kernels). That was evident by files fragmenting even with the attribute set. Chris mentioned to find a fix quickly for that, and posted some lines of change into irc. But recently someone mentioned that 3.6-rc looks like still not respecting nocow for files. Is there really

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

To make Btrfs code more robust, several return value checks where memory allocation can fail are introduced. I use BUG_ON where I don''t know how to handle the error properly, which increases the number of using the notorious BUG_ON, though. Signed-off-by: Yoshinori Sano <yoshinori.sano@gmail.com> --- fs/btrfs/compression.c | 6 ++++++ fs/btrfs/extent-tree.c | 2 ++

I''ve been working to try to improve the write-ahead log''s performance, and I found that the bottleneck addresses in the checksum items, especially when we want to make a random write on a large file, e.g a 4G file. Then a idea for this suggested by Chris is to use sub transaction ids and just to log the part of inode that had changed since either the last log commit or the last

Hi all - Here''s my current error handling patchset, against 3.1-rc8. Almost all of this patchset is preparing for actual error handling. Before we start in on that work, I''m trying to reduce the surface we need to worry about. It turns out that there is a ton of code that returns an error code but never actually reports an error. The patchset has grown to 65 patches. 46 of them

We''ve been keeping around the inode sequence number in hopes that somebody would use it, but nobody uses it and people actually use i_version which serves the same purpose, so use i_version where we used the incore inode''s sequence number and that way the sequence is updated properly across the board, and not just in file write. Thanks, Signed-off-by: Josef Bacik

If we have particularly full nodes, we could call btrfs_node_blockptr up to 32 times, which is 32 pairs of kmap/kunmap, which _sucks_. So go ahead and map the extent buffer while we look for readahead targets. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/ctree.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git

I removed this in an earlier commit and I was wrong. Because compression can return from filemap_fdatawrite() without having actually set any of it''s pages as writeback() it can make filemap_fdatawait() do essentially nothing, and then we won''t find any ordered extents because they may not have been created yet. So not only does this make fsync() completely useless, but it will

Just a quick update, I''ve dropped the hashing stuff in favor of doing a memcmp in the kernel to make sure the data is still the same. The thing that takes a while is reading the data up from disk, so doing a memcmp of the entire buffer isn''t that big of a deal, not to mention there''s a possiblity for malicious users if there is a problem with the hashing algorithms we

Hi, The following series of patches implements in btrfs an ioctl to do out-of-band deduplication of file extents. To be clear, this means that the file system is mounted and running, but the dedupe is not done during file writes, but after the fact when some userspace software initiates a dedupe. The primary patch is loosely based off of one sent by Josef Bacik back in January, 2011.

To make Btrfs code more robust, several return value checks where memory allocation can fail are introduced. I use BUG_ON where I don''t know how to handle the error properly, which increases the number of using the notorious BUG_ON, though. Signed-off-by: Yoshinori Sano <yoshinori.sano@gmail.com> --- fs/btrfs/compression.c | 6 ++++++ fs/btrfs/extent-tree.c | 4 ++++

We''re going to use this flag EXTENT_DEFRAG to indicate which range belongs to defragment so that we can implement snapshow-aware defrag: We set the EXTENT_DEFRAG flag when dirtying the extents that need defragmented, so later on writeback thread can differentiate between normal writeback and writeback started by defragmentation. This patch is used for the latter one. Originally patch

The original truncation of btrfs has a bug, that is the orphan item will not be dropped when the truncation fails. This bug will trigger BUG() when unlink that truncated file. And besides that, if the user does pre-allocation for the file which is truncated unsuccessfully, after re-mount(umount-mount, not -o remount), the pre-allocated extent will be dropped. This patch modified the relative

I noticed that if the free space cache has an error writing out it''s data it won''t actually error out, it will just carry on. This is because it doesn''t check the return value of btrfs_wait_ordered_range, which didn''t actually return anything. So fix this in order to keep us from making free space cache look valid when it really isnt. Thanks, Signed-off-by:

This happens on a freshly created btrfs filesystem in a raid10 (4x1TB) configuration with three subvolumes and 1.5 TB data. When I try to snapshot one of the subvolumes (with 100 GB of data), it says that the snapshot creation failed and I get the following error message: btrfs: could not do orphan cleanup -116 After the failure: - The snapshot exists in `btrfs subvolume list'' - The

Even though we allocate more, we should be updating inode i_size as per the arguments passed Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- Changes from V1: We should update i_size only if actual_len and cur_offset are both larger than i_size. Otherwise if actual_len is < i_size and cur_offset > i_size we may end up setting wrong i_size value