coreutils
[Top][All Lists]
Advanced

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

Re: Feature request: Add fibmap/SEEK_HOLE support to sha1sum.


From: Chris Dew
Subject: Re: Feature request: Add fibmap/SEEK_HOLE support to sha1sum.
Date: Thu, 5 Sep 2013 16:58:18 +0100

Thanks Pádraig,

I had avoided fiemap, due to the issue discussed at http://smackerelofopinion.blogspot.co.uk/2010/01/using-fiemap-ioctl-to-get-file-extents.html - I use fibmap instead, but it's only for root.

Is fiemap now safe?

All the best,

Chris.

P.S. If you hadn't noticed, that was one of my StackOverflow questions :-)  I get a bit of sparse file related work off of the back of http://www.virtsync.com


On 5 September 2013 14:20, Pádraig Brady <address@hidden> wrote:
On 09/05/2013 12:45 PM, Chris Dew wrote:
> Hi,
>
> I have a customer who has several broken CentOS systems which behave badly when reading holes from sparse files (cause not yet discovered).
>
> They are asking for fibmap and optionally SEEK_HOLE support in sha1sum.  I would be happy to add these for them.  If I did so, would coreutils accept a patch for such features?  (I believe these would only yield a marginal performance increase on non-broken systems.)
>
> If so, would I be better autodetecting fibmap and SEEK_HOLE support, or doing this via command line switches?

We already have fiemap support for detecting holes,
which is used by cp for sparse files.
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/extent-scan.c;hb=HEAD
SEEK_HOLE came later to Linux than fiemap and has a cleaner
more focused interface than fiemap.
I'd be happy using either interface TBH.

Such a change would require copyright attribution, See "Copyright assignment" in:
http://git.savannah.gnu.org/cgit/coreutils.git/plain/HACKING

In general any of the coreutils that operate on binary data (blocks)
rather than textual data (lines) could make use of hole detection.
Since checksum utils are often used with large files, they would
be good candidates to add hole detection to.

Note as well improved read efficiencies, there might be
some processing efficiencies possible too:
http://stackoverflow.com/q/15007629/4421

thanks,
Pádraig.


reply via email to

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