On 2015å05æ04æ 10:02, Dave Chinner wrote:
> [cc fstests@xxxxxxxxxxxxxxxx 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.
>
|