coreutils
[Top][All Lists]
Advanced

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

Re: coreutils-8.15.74-be17e3 on OpenBSD


From: Jim Meyering
Subject: Re: coreutils-8.15.74-be17e3 on OpenBSD
Date: Sat, 17 Mar 2012 12:28:07 +0100

Pádraig Brady wrote:

> On 03/17/2012 10:11 AM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>>> This is from the dd/sparse failure:
>>>
>>> On 03/17/2012 02:31 AM, Bruno Haible wrote:
>>>> + alloc_equal file.in file.out
>>>> + : 4
>>>> +++ stat -c %b file.in
>>>> +++ stat -c %b file.out
>>>> ++ expr 4160 - 4128
>>>> + alloc_diff=32
>>>> ++ echo 32
>>>> ++ tr -d -- -
>>>> + alloc_diff=32
>>>> + test 32 -le 4
>>>> + fail=1
>>>
>>> That confirms that sparse granularity is
>>> coarser than I assumed on the BSDs.
>>>
>>> Perhaps this is appropriate:
>>>
>>> diff --git a/tests/dd/sparse b/tests/dd/sparse
>>> index 17aa94b..203e103 100755
>>> --- a/tests/dd/sparse
>>> +++ b/tests/dd/sparse
>>> @@ -51,10 +51,10 @@ dd if=/dev/urandom of=file.in bs=1M count=1 
>>> conv=notrunc oflag=append
>>>  # but can vary by a file system block due to alignment,
>>>  # which was seen on XFS at least.
>>>  alloc_equal() {
>>> -  : ${sectors_per_block:=$(expr $(stat -f -c "%S" .) / 512)}
>>> +  : ${sectors_per_sparse_block:=$(expr $(stat -f -c "%S" .) / 64)}
>>>    alloc_diff=$(expr $(stat -c %b "$1") - $(stat -c %b "$2"))
>>>    alloc_diff=$(echo $alloc_diff | tr -d -- -) # abs()
>>> -  test $alloc_diff -le $sectors_per_block
>>> +  test $alloc_diff -le $sectors_per_sparse_block
>>>  }
>>
>> Thanks.  That looks fine.
>> I've just confirmed that it passes on gcc66 (sparc64 OpenBSD 5.1)
>
> Or maybe `stat -c %o` is less arbitrary and seemed
> to work previously in another test even though
> it doesn't seem like it should directly correlate.

I agree that the 512->64 change feels arbitrary in the sense that
it's tailored to the lowest common denominator we've seen so far.
Thus we might well have to reduce it further to avoid a false positive
for some other type of file system.  But that seems ok for now.

If we can find that the "optimal I/O transfer size hint"
correlates on a wide enough selection of file system types,
we can switch to that approach later.

Have a nice break.



reply via email to

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