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... -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
