[Top][All Lists]

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

bug#6131: [PATCH]: fiemap support for efficient sparse file copy

From: Paul Eggert
Subject: bug#6131: [PATCH]: fiemap support for efficient sparse file copy
Date: Thu, 15 Jul 2010 15:31:52 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100527 Thunderbird/3.0.5

>>> This doesn't sound right.  A FIEMAP_EXTENT_UNWRITTEN extent is all zeros, 
>>> and
>>> so it should act as if it were a hole.  The goal is not to copy the exact
>>> fiemap structure of the source (that's impossible): the goal is to use as
>>> little time and space as possible.

> A FIEMAP_EXTENT_UNWRITTEN extent is marked to allocated although
> read it will return ZEROs through the filesystem.  So why not using
> fallocate(2) to deal with it?  IMHO, it meet the goal to use little
> time and space as possible, Am I miss something?

It's faster to simply skip around that extent while reading it, and to
skip around it when writing it, than to call fallocate when writing it.
Logically, a FIEMAP_EXTENT_UNWRITTEN extent is a hole, and should be
optimized when reading, just like any hole.

>> I see fiemap as optimizing reads,
>> posix_fallocate() as optimizing writing zeros
>> and fallocate() as optimizing allocation.

It may not be quite that simple.  Some platforms won't have fallocate
and so posix_fallocate will have to do double duty as optimizing
allocation too.  Also, lseek is part of the process of optimizing
reads, and of optimizing writing zeros.  And fallocate also optimizes
writing zeros, I expect.

I'm not objecting to breaking these improvements into two or three
pieces, if someone wants to do that.  However, it shouldn't be
required to break them up; it's OK if someone wants to do it all at
once.  (This stuff is not that hard, after all.)  I was planning to
give it a shot at some point but obviously have not done so yet.

reply via email to

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