[PATCH] Btrfs: fix defrag regression

If a file has 3 small extents: | ext1 | ext2 | ext3 | Running btrfs fi defrag will only defrag the last two extents, if those extent mappings hasn't been read into memory from disk. This bug was introduced by commit 17ce6ef8d731af5edac8c39e806db4c7e1f6956f (Btrfs: add a check to decide if we

[PATCH] Btrfs: fix incompat flags setting

It's a bug, but it happens to work, as BTRFS_COMPRESS_LZO == 2, which has only one bit set. Signed-off-by: Li Zefan lize...@huawei.com --- fs/btrfs/disk-io.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 7ae51de..fe82070

Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems

On Sat, Jun 09, 2012 at 12:25:57AM -0700, Andrew Morton wrote: And... it seems that I misread what's going on. The individual filesystems are doing the rcu freeing of their inodes, so it is appropriate that they also call rcu_barrier() prior to running kmem_cache_free(). Which is what

[PATCHv4 3/4] avoid several strncpy-induced buffer overruns

Hugo Mills wrote: Hi, Jim, I picked this up to go in integration-*, and Alex Block spotted a problem, so I did a bit of a more in-depth review. Comments below. Hi Hugo, Thanks again for the review feedback. ... TL;DR: the length of btrfs_ioctl_vol_args.name depends on #ifdef

Re: [PATCH 1/2] Btrfs: use rcu to protect device-name

On Tue, Jun 05, 2012 at 02:16:32PM -0400, Josef Bacik wrote: Al pointed out that we can just toss out the old name on a device and add a new one arbitrarily, so anybody who uses device-name in printk could possibly use free'd memory. Instead of adding locking around all of this he suggested

[PATCH] Btrfs: use rcu to protect device-name V2

Al pointed out that we can just toss out the old name on a device and add a new one arbitrarily, so anybody who uses device-name in printk could possibly use free'd memory. Instead of adding locking around all of this he suggested doing it with RCU, so I've introduced a struct rcu_string that

[PATCH] Btrfs: call filemap_fdatawrite twice for compression V2

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

Re: [PATCH] Btrfs: use rcu to protect device-name V2

- if (state-print_mask BTRFSIC_PRINT_MASK_SUPERBLOCK_WRITE) + if (state-print_mask BTRFSIC_PRINT_MASK_SUPERBLOCK_WRITE) { + struct rcu_string *name; + + rcu_read_lock(); + name =

Re: KVM on top of BTRFS

Matthew Hawn steamraven at yahoo.com writes: What are the recommendations for running KVM images on BTRFS systems using kernel 3.4?  I saw older posts on the web complaining about poor performance, but I know a lot of work has gone into btrfs since then.  There also seemed to be the nocow

Re: KVM on top of BTRFS

On 06/12/2012 08:53 AM, Alex wrote: Matthew Hawn steamraven at yahoo.com writes: What are the recommendations for running KVM images on BTRFS systems using kernel 3.4? I saw older posts on the web complaining about poor performance, but I know a lot of work has gone into btrfs since then.