All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Sheng-Hui <shhuiw@foxmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs <xfs@oss.sgi.com>
Subject: Re: xfstests: what's the difference between generic/043 and generic/044
Date: Mon, 04 May 2015 10:25:30 +0800	[thread overview]
Message-ID: <5546D89A.1070504@foxmail.com> (raw)
In-Reply-To: <20150504020242.GB21261@dastard>



On 2015年05月04日 10:02, Dave Chinner wrote:
> [cc fstests@vger.kernel.org. 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 &gt; /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 &gt; /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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2015-05-04  2:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-04  1:49 xfstests: what's the difference between generic/043 and generic/044 Wang Sheng-Hui
2015-05-04  2:02 ` Dave Chinner
2015-05-04  2:25   ` Wang Sheng-Hui [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5546D89A.1070504@foxmail.com \
    --to=shhuiw@foxmail.com \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.