Re: coreutils-8.10 released [stable]

[Jim Meyering]

Pádraig Brady wrote:
> On 05/02/11 07:30, Jim Meyering wrote:
>> Dmitry V. Levin wrote:
>>> On Fri, Feb 04, 2011 at 08:20:39PM +0100, Jim Meyering wrote:
>>>> This is to announce coreutils-8.10, a stable release.
>>>>
>>>> There have been some minor bug fixes, along with two new features.  The
>>>> join feature is enabled via a new option, "-o auto".  The cp feature makes
>>>> copying sparse files much more efficient on several common file systems.
>>>> It takes advantage of a feature that was introduced in linux-2.6.27.
>>>> The improvement affects the default code path, so if you're looking
>>>> for risk potential, this is it.  It uses the feature if available,
>>>> and otherwise resorts to using the old, less-efficient copying code.
>>>
>>> tests/cp/fiemap-perf fails with EFBIG on tmpfs:
>>> $ truncate -s1T f
>>> truncate: failed to truncate `f' at 1099511627776 bytes: File too large
>>>
>>> Reducing the size from 1T to 256G makes the test pass.
>>
>> Thanks for the report.
>> The current df-based guard for the cp/FIEMAP tests
>> is a kludge^W heuristic that will soon be replaced by
>> Pádraig's python-based test:
>>
>> http://thread.gmane.org/gmane.comp.gnu.coreutils.general/821/focus=839
>
> Yep, just did that, and got a couple of failures for sparse-fiemap
> on and ext3 and loopback ext4 file systems.
> On a very quick glance, I think cp is OK and that the filefrag
> matching is a bit brittle.
> Attached are filefrag outputs.

I saw similar differences, but I think they were due to the fact that
the kernel had not yet forced cp's metadata update to disk when filefrag
does its FIEMAP ioctl

Uncommenting the "sync" just after the "cp" in the sparse-fiemap test
solved the problem (for me it arose only on rawhide's btrfs) but made
the test take a lot more time, as mentioned in the comment.

Instead of that sync, using filefrag's -s option may
have the same result without the unwanted overhead.

> Filesystem type is: ef53
> File size of j2 is 2048 (2 blocks, blocksize 1024)
>  ext logical physical expected length flags
>    0       0        0               2 unknown,delalloc,eof
> j2: 1 extent found
>
> Filesystem type is: ef53
> File size of j1 is 2048 (2 blocks, blocksize 1024)
>  ext logical physical expected length flags
> j1: 1 extent found