On Fri, Jul 01, 2016 at 10:28:28AM +0800, Wang Xiaoguang wrote: > hello, > > On 06/30/2016 09:52 PM, Eryu Guan wrote: > > On Thu, Jun 30, 2016 at 04:25:49PM +0800, Wang Xiaoguang wrote: > > > In btrfs, when truncate operation fails for enospc reason, file may still > > > have some disk blocks, but it will fail to update filesize accordingly. > > > > > > Kernel commit c0d2f61 has fixed this bug for btrfs: > > > btrfs: fix disk_i_size update bug when ftruncate() fails > > > > > > Signed-off-by: Wang Xiaoguang <wangxg.fnst@xxxxxxxxxxxxxx> > > > --- > > > v2: move this test to generic test and add comments why testcase > > > use reflink. > > Thanks for the updated version. Did it fail for you when testing on > > unpatched kernel? I ran the test more than 10 times on 4.6 kernel (which > > doesn't have the fix) and all passed, as well as RHEL7 kernel. > > > > Can you please confirm? > I tested this case in v4.6-rc7-162-g415b35a and it failed as expected, > but I used the newest version btrfs-progs. > In RHEL7.2ga, its btrfs-progs version is btrfs-progs-3.19.1-1.el7.x86_64, > which is somewhat old. For small fs, it'll enable mixed mode for data and > metadata default, so the reflink operation in this test case does not > consume > enough metadata, truncate operation can still succeed, then test will always > pass. I can create a big fs to have test, but then this fs will have more > metadata, which then need more reflink operations to consume metadata and > increase the test time greatly. > > In mkfs.btrfs manpage, there is such description： > versions up to 4.2.x forced the mixed mode for devices smaller > than 1GiB. This has been removed in 4.3+ as it caused some > usability issues. I also tested on 4.6 kernel with v4.6 btrfs-progs, it passed 10+ times without a fail. I was testing on a 4vcpu kvm guest with 8G memory, TEST_DEV and SCRATCH_DEV are all 15G in size, not sure if that matters. Thanks, Eryu -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
