coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ready for release of coreutils-8.11?


From: Eric Sandeen
Subject: Re: ready for release of coreutils-8.11?
Date: Tue, 12 Apr 2011 20:05:00 -0500
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9

On 4/12/11 7:08 PM, Pádraig Brady wrote:
> On 12/04/11 15:35, Eric Sandeen wrote:
>> On 4/12/11 9:04 AM, Pádraig Brady wrote:
>>> On 12/04/11 13:09, Jim Meyering wrote:
>>>> Pádraig Brady wrote:
>>>>> On 12/04/11 11:59, Jim Meyering wrote:
>>>>>> Pádraig Brady wrote:
>>>>>>> On 11/04/11 21:09, Jim Meyering wrote:
>>>>>>>> I've run the test suite on F15 x86_64 using each of ext3, ext4, btrfs 
>>>>>>>> and xfs.
>>>>>>>> All tests passed on the first three FS types.
>>>>>>>> On xfs there was only one failure: cp/sparse-fiemap.
>>>>>>>> I pared it down to this stand-alone reproducer:
>>>>>>>>
>>>>>>>>     rm -f j1 j2
>>>>>>>>     perl \
>>>>>>>>       -e 'BEGIN{$n=7*1024; *F=*STDOUT}' \
>>>>>>>>       -e 'for (1..21) { sysseek (*F, $n, 1)' \
>>>>>>>>       -e '&& syswrite (*F, chr($_)x$n) or die "$!"}' > j1
>>>>>>>>     cp --sparse=always j1 j2
>>>>>>>>     diff -u <(filefrag -v j1) <(filefrag -vs j2)
>>>>>>>>
>>>>>>>> Here's the output.
>>>>>>>> The difference that triggers the test failure is
>>>>>>>> the fact that the "length" numbers differ:
>>>>>>>>
>>>>>>>>     --- /proc/self/fd/11    2011-04-11 22:01:00.932737472 +0200
>>>>>>>>     +++ /proc/self/fd/12    2011-04-11 22:01:00.932737472 +0200
>>>>>>>>     @@ -1,6 +1,6 @@
>>>>>>>>      Filesystem type is: 58465342
>>>>>>>>     -File size of j1 is 301056 (74 blocks, blocksize 4096)
>>>>>>>>     +File size of j2 is 301056 (74 blocks, blocksize 4096)
>>>>>>>>       ext logical physical expected length flags
>>>>>>>>     -   0       1     7310              31
>>>>>>>>     -   1      33     7342     7340     95 eof
>>>>>>>>     -j1: 3 extents found
>>>>>>>>     +   0       1     7469              31
>>>>>>>>     +   1      33     7501     7499     63 eof
>>>>>>>>     +j2: 3 extents found
>>>>>>>
>>>>>>> Hmm, this is with 128K block sizes?
>>>>>>
>>>>>> The perl snippet performs 21 pairs of lseek/syswrite calls,
>>>>>> each of length 7KiB.  Not sure about the 3 extents, or why
>>>>>> only the first 4KiB block and one other in the middle of the
>>>>>> file end up being holes on XFS.
>>>>>
>>>>>> Hey, do you feel like extending your fiemap-capable script
>>>>>> to print FIEMAP data?  Then we wouldn't have to rely on filefrag,
>>>>>> which appears to be confused here.
>>>>>
>>>>> I'm not sure filefrag is at fault here.
>>>>> It just shifts and prints the returned lengths.
>>>>> Could you post the output of this (with the -r option)
>>>>> http://oss.oracle.com/~mason/fiemap-test.c
>>>>
>>>> Good idea.
>>>>
>>>>   $ gcc -O -Wall fiemap-test.c
>>>>   fiemap-test.c: In function 'show_extents_table':
>>>>   fiemap-test.c:138:9: warning: variable 'last_logical' set but not used \
>>>>     [-Wunused-but-set-variable]
>>>>
>>>> Note that here I'm using 1..31, not 1..21:
>>>>
>>>>   $ rm -f j1 j2; perl -e 'BEGIN{$n=7*1024; *F=*STDOUT}' \
>>>>     -e 'for (1..31) { sysseek (*F, $n, 1)' \
>>>>     -e '&& syswrite (*F, chr($_)x$n) or die "$!"}' > j1
>>>>   $ cp --sparse=always j1 j2 && cmp j1 j2
>>>>
>>>> Uh oh.  du reports different sizes:
>>>>
>>>>   $ du -sh j1 j2
>>>>   504K    j1
>>>>   632K    j2
>>>>
>>>> Not only that, but note how the sizes are *larger*
>>>> than raw byte counts.  This means there's a hole at EOF:
>>>>
>>>>   $ wc -c j1 j2
>>>>   444416 j1
>>>>   444416 j2
>>>>
>>>> Here's the result of running fiemap-test:
>>>>
>>>>   $ {./a.out -r j1; ./a.out -r j2}|sed 's/:   /:/g'
>>>>   Extent   0: logical:    4096 physical: 4272128 length:  126976 flags 
>>>> 0x000
>>>>   Extent   1: logical:  135168 physical: 4403200 length:  389120 flags 
>>>> 0x001
>>>>   Extent   0: logical:    4096 physical: 4792320 length:  126976 flags 
>>>> 0x000
>>>>   Extent   1: logical:  135168 physical: 5193728 length:  520192 flags 
>>>> 0x001
>>>>
>>>> No wonder those final "length" numbers differed.
>>>> This looks like an XFS bug.
>>>
>>> Well not necessarily.
>>> I suppose that XFS may be allocating the extents differently
>>> in the destination for performance reasons.
>>> I.E. It's laying out the 128KiB chunks first and not
>>> trimming trailing slop.
>>>
>>> So if that was the case, we'd have to get our fiemap comparison
>>> to discount anything after a specified length.
>>
>> I'd say don't get too fancy.
>>
>> The only thing the fileystem needs to get right on the copy is file size and 
>> contents.
>> If those match after a copy, the test should pass.
> 
> Right. However, we'd like to verify that holes
> are being propagated from source to dest,
> and a fiemap list is the only way I know to test that.

But unfortunately the filesystem is not actually required to put a hole 
anywhere...

> Also it's unlikely I think that holes would be
> introduced differently in the dest, given the
> processing that cp does.

Depends on what writeback is doing during the test, etc, and probably many 
other things.

> So I'm leaning towards relaxing the test,
> by ignoring the length of the last extent
> along the lines of the following.

I think it's fragile because the fs can change behavior at will.  But it's your 
testcase. :)

-Eric

> cheers,
> Pádraig.
> 
> diff --git a/tests/filefrag-extent-compare b/tests/filefrag-extent-compare
> index 2c33584..c8b840c 100644
> --- a/tests/filefrag-extent-compare
> +++ b/tests/filefrag-extent-compare
> @@ -56,11 +56,24 @@ merge_extents \@b;
>  my $i = 0;
>  while (defined $a[$i])
>    {
> -    $a[$i]->{L_BLK} == $b[$i]->{L_BLK} && $a[$i]->{LEN} == $b[$i]->{LEN}
> -      or die "$ME: differing extent:\n"
> -        . "  [$i]=$a[$i]->{L_BLK} $a[$i]->{LEN}\n"
> -          . "  [$i]=$b[$i]->{L_BLK} $b[$i]->{LEN}\n";
> -    $i++;
> +    if ($a[$i]->{L_BLK} == $b[$i]->{L_BLK} && $a[$i]->{LEN} == $b[$i]->{LEN})
> +      {
> +        $i++;
> +      }
> +    elsif ($i == (@a - 1) && $a[$i]->{L_BLK} == $b[$i]->{L_BLK})
> +      {
> +        # On XFS it was seen that the size of the last extent can vary,
> +        # and can extend beyond the length of the file.
> +        # So ignore the length of the last extent, because if the
> +        # file is the wrong length we'll get failures elsewhere.
> +        last;
> +      }
> +    else
> +      {
> +        die "$ME: differing extent:\n"
> +          . "  [$i]=$a[$i]->{L_BLK} $a[$i]->{LEN}\n"
> +            . "  [$i]=$b[$i]->{L_BLK} $b[$i]->{LEN}\n";
> +      }
>    }
> 
>  ### Setup "GNU" style for perl-mode and cperl-mode.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]