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