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.
