[Top][All Lists]

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

Re: [PATCH] copy: adjust fiemap handling of sparse files

From: Jim Meyering
Subject: Re: [PATCH] copy: adjust fiemap handling of sparse files
Date: Fri, 18 Mar 2011 12:52:43 +0100

Pádraig Brady wrote:
> On 17/03/11 23:00, Pádraig Brady wrote:
>> On 17/03/11 19:29, Mike Frysinger wrote:
>>> On Thursday, March 17, 2011 05:32:33 Pádraig Brady wrote:
>>>> This is the kind of patch appropriate for a distro,
>>>> as they may or may not have a fix backported to their kernel.
>>> Gentoo, being a source distribution, has no kernel requirement.  people are
>>> free to run on pretty much anything.  we dont have the luxury of saying
>>> "upgrade your kernel package and reboot".  especially since we also support
>>> running Gentoo inside of other distros (often times as non-root user) where
>>> people dont have the ability at all to upgrade.
>>>> I presume you're referring to coreutils bug 8001.
>>>> I didn't realise ext4 was also affected.
>>>> Is this specific to the compress flag?
>>>> What was the specific fix to btrfs &/or ext4 in 2.6.38?
>>> this is the ext4-specific issue i'm avoiding:
>> Ah that issue. That's what the syncing required in this test
>> was working around:
>> Note Fedora 15 about to be released is using the new fiemap code in cp,
>> but is also based on 2.6.38 and so will have the fix soon,
>> if it does not already have it.
> I also now remember this discussion:
> where FIEMAP_FLAG_SYNC was introduced in cp,
> I think to work around this same bug in BTRFS and EXT4.
> This flag in ineffective though on ext4 loopback
> and thus I needed to add the syncs to the test as ref'd above.
>>>> Also note the make_holes heuristic variable is no
>>>> longer used in extent_copy due to this patch which
>>>> came after the 8.10
>>> i'll worry about it once 8.11 is released ;)
>>> -mike
>> You might be safer to just bypass extent_copy for kernels < 2.6.38
>> I'm 30:70 for doing that in upstream coreutils
> So am I right in thinking FIEMAP_FLAG_SYNC is no longer needed with 2.6.38.
> I'm quite worried about implicit syncing in cp actually, where it might
> introduce bad performance regressions.

Good point.

> Maybe we could disable this flag if XFS || kernel >= 2.6.38?
> Or maybe we might do as you suggest above and disable extent_copy()
> completely, for kernels before 2.6.38.
> Not an ideal situation at all :(

If there really is risk of data loss with ext4 on kernels < 2.6.38,
even if it's only on unusual files, then we'll have to consider
using a kernel version check to disable extent_copy.

Is there a stand-alone ext4 reproducer?

reply via email to

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