On Thu, Jun 15, 2017 at 09:19:44AM -0500, Eric Sandeen wrote: > On 6/15/17 3:12 AM, Xiao Yang wrote: > > On 2017/05/20 10:25, Eric Sandeen wrote: > >> > >> On 5/19/17 11:39 AM, Eric Sandeen wrote: > >>> On 5/18/17 10:30 PM, Eric Sandeen wrote: > >>> > >>>> That's an odd failure; I wrote the test for upstream... > >>>> > >>>> On that kernel, despite free inodes: > >>>> > >>>> # df -i /mnt/scratch > >>>> Filesystem Inodes IUsed IFree IUse% Mounted on > >>>> /dev/loop1 10260 490 9770 5% /mnt/scratch > >>>> > >>>> and xfs_db concurs (more or less?): > >>>> > >>>> icount = 10240 > >>>> ifree = 9750 > >>>> > >>>> creating a new inode fails: > >>>> > >>>> # touch /mnt/scratch/testdir/12345678901234567890169 > >>>> touch: cannot touch ‘/mnt/scratch/testdir/12345678901234567890169’: No space left on device > >>>> > >>>> Everything about the fs looks the same as if we run it upstream, including > >>>> the reserved blocks: > >>>> > >>>> reserved blocks = 6553 > >>>> available reserved blocks = 6553 > >>>> > >>>> But, it's failing to allocate the space: > >>>> > >>>> touch-12302 [005] d... 118038.499302: ret_xfs_mod_fdblocks: (xfs_trans_reserve+0x123/0x200 [xfs]<- xfs_mod_fdblocks) arg1=0xffffffe4 > >>>> > >>>> (arg1 is the return value, -ENOSPC) > >>>> > >>>> It's not clear to me at this point why we can't create another inode on this fs. > >>> Ugh, I can't believe I missed this - I actually didn't do anything to ensure that > >>> there is free space to grow the actual directory into. > >>> > >>> If I add this just prior to the last 1300-file touch loop: > >>> > >>> ./src/punch-alternating $SCRATCH_MNT/spacefile1>> $seqres.full 2>&1 > >>> > >>> that seems to let the test proceed w/o ENOSPC, and properly fragment the > >>> dir. > >>> > >>> (OTOH upstream, now the test is reporting fs corruption, though I don't > >>> see it after the test completes. Very confused now. It might be > >>> confusing xfs_check? Repair is happy...) > >>> > >>> I'm still not sure why the rhel kernel differs from upstream, though. > >> The more I look at this, the more I realize how fragile the test is. It's > >> trying to control allocation, which is almost nearly impossible to do > >> reliably in a test. > >> > >> I'm not quite sure how to make this one better... > > Hi Eric > > > > Sorry for the late reply. > > > > Firstly, The following command works abnormally on RHEL7.3 and RHEL7.4. > > dd conv=fsync if=/dev/zero of=$SCRATCH_MNT/spacefile2 bs=1M count=64 > > > > If bs is set to 1M and the remaining freespace is less than 1M, dd could not write any data > > into spacefile2. However, it still writes data into spacefile2 and leads that there is no > > enough free space to grow the actual directory. > > > > Secondly, I tested this case with upstream kernel in RHEL7.3 on virtual machine, but i awlays don't > > trigger this bug. Is there some specific settings? > > > > Could we use the following command to consume a lot of remaining free space, but reserve > > some free space to create the last 1300-file: > > dd conv=fsync if=/dev/zero of=$SCRATCH_MNT/spacefile2 bs=1K count=35000 > > > > I am not sure if this change can still trigger kernel bug. :-) > > Honestly, I think this test should probably be removed. It's trying too hard to > control allocation behavior, which is not possible in general. > > The only other approach I can think of is to create a lot of one-block files, > map them all, and then decide which ones to remove (or perhaps better, truncate to > 0 length) in an effort to create perfectly fragmented freespace. At least that > way we would not be trying control or expect allocation patterns ahead of time. <shrug> There are common/ helpers to fill up a filesystem, why not use that instead of open-coding it? This test uncovered a somewhat obscure corruption bug, which to me argues for /not/ kicking this one out. --D > > -Eric > -- > 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 -- 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
