coreutils
[Top][All Lists]
Advanced

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

Re: coreutils-8.10 released [stable]


From: Pádraig Brady
Subject: Re: coreutils-8.10 released [stable]
Date: Mon, 07 Feb 2011 12:39:27 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

On 05/02/11 13:59, Jim Meyering wrote:
> Pádraig Brady wrote:
>> 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.

It seems that the sync is needed for ext4 loop back also, on my system.
However for ext3, the extents between src and dst still don't match up.
My systems uses a 4K block size and is 2.6.35.10-72.fc14.i686
For now, I've disabled (indirectly) using ext3 for fiemap-perf and
sparse-fiemap in the attached.

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

That doesn't work actually which baffles me.
I got the e2fsprogs source rpm to verify that
FIEMAP_FLAG_SYNC was set, so I guess this is a kernel issue
(on ext4 loop back at least).
Though I was able to get a a working sync restricted to the file
by using dd in the attached patch.
Even with that, the test only takes about 10s on my old laptop, so
I didn't bother tagging the test as EXPENSIVE.

cheers,
Pádraig.

Attachment: fiemap-capable.diff
Description: Text Data


reply via email to

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