bug#6131: [PATCH]: fiemap support for efficient sparse file copy (original) (raw)

[Top][All Lists]

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

From: Joel Becker
Subject: bug#6131: [PATCH]: fiemap support for efficient sparse file copy
Date: Tue, 15 Jun 2010 15:41:10 -0700
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, Jun 15, 2010 at 03:30:15PM -0700, Sunil Mushran wrote:

On 06/15/2010 03:19 PM, Paul Eggert wrote: >This all is getting a bit complicated, I'm afraid. Perhaps it'd be better >to try this stuff out with a new option, "cp --sparse=extents" say, and >keep the default as-is for a while?

Expecting to control the number of extents in a file in any file system is expecting too much of the fs. No file system guarantees that. fallocate() only allocates the space. It does not give any guarantees for the number of extents.

    I don't think it's ever interesting to try and mimic the source

file's extent pattern. Really, what's the point? I have done a lot of administration in my time, and I've worked with a lot of people. I've never needed nor heard anyone ask for this capability. What people want is "--sparse=always, but not slow". Either they know their input file has 100MB holes, and they want their destination to have 100MB holes or they have a 100MB file that has few zeros, and they wouldn't mind those zeros being unallocated. What they really don't want is to wait while the CPU churns figuring this out. When people choose "--sparse=auto", they don't mean they want non-sparse files; they just want to avoid lots of work for a file that isn't very sparse. With fiemap, cp can give them the best of both worlds.

Joel

--

"You must remember this: A kiss is just a kiss, A sigh is just a sigh. The fundamental rules apply As time goes by."

Joel Becker Principal Software Developer Oracle E-mail: address@hidden Phone: (650) 506-8127