On 2015年05月04日 10:02, Dave Chinner wrote: > [cc fstests@xxxxxxxxxxxxxxx. Please send xfstests questions there. ] > > On Mon, May 04, 2015 at 09:49:20AM +0800, Wang Sheng-Hui wrote: >> Hi, >> >> I'm reading the source code of generic/044 in xfstests, and I cannot figure out the >> difference compared with 043 testcase: >> ------------------------------------------------------------------------------- >> $ diff -Nu 043 044 >> --- 043 2015-03-09 10:03:48.013887582 +0800 >> +++ 044 2015-03-09 10:03:48.013887582 +0800 >> @@ -1,5 +1,5 @@ >> #! /bin/bash >> -# FSQA Test No. 043 >> +# FSQA Test No. 044 >> # >> # Test for NULL files problem >> # >> @@ -56,6 +56,12 @@ >> echo error creating/writing file $file >> exit >> fi >> + xfs_io -c "truncate 64k" $file > /dev/null >> + if [ $? -ne 0 ] >> + then >> + echo error truncating file $file >> + exit >> + fi >> let i=$i+1 >> done >> >> >> But before the 'truncate 64K', only 64K sized files are created: >> xfs_io -f -c "pwrite -b 64k -S 0xff 0 64k" $file > /dev/null >> So I think it's useless here, or some typo e.g smaller truncate needed? > > It's testing a corner case in the truncate code, where new_size == > old_size. Go back years ago (i.e. before ~2007) when the "NULL > files" problem existed, this would result in XFS writing a size of > 64k to the inode, but none of the data written into the kernel would > exist on disk. Hence you'd get a "NULL file" after crash recovery > if you did this. > > generic/043 is simply testing write without truncate - the result > there was dependent on timing of writeback, so not guaranteed to > fail. The truncate case pretty much guaranteed NULL files would > exist and so the test always failed.... Thanks for your explanation, Dave. Regards, Sheng-Hui > > Cheers, > > Dave. > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
