bug-tar
[Top][All Lists]
Advanced

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

Re: [Bug-tar] Sparse file performance and suggestions


From: Joerg Schilling
Subject: Re: [Bug-tar] Sparse file performance and suggestions
Date: Mon, 07 Feb 2011 17:24:30 +0100
User-agent: nail 11.22 3/20/05

Eric Blake <address@hidden> wrote:

> > I asume that you are testing on a OS that does not implement 
> > SEEK_HOLE/SEEK_DATA, as star is even faster that GNU tar in case that the 
> > OS 
> > helps to retrieve the sparse file info.
>
> Solaris has SEEK_HOLE, although the new coreutils cp code for using
> efficient sparse traversal has not yet been ported to use it.  It's on
> the list of things to implement (and has been for more than 6 months).

Jeff Bonwick and I defined the SEEK_HOLE/SEEK_DATA interface in September 2004, 
and I implemented support for it in star in May 2005 - a few weeks after the 
implementation in Solaris was ready. At that time, there was nothing similar 
and I was in hope that other OS just reimplement this useful idea.

> Linux has ioctl(FIEMAP), which is just as efficient as Solaris'
> SEEK_HOLE, and coreutils 8.10 is the first GNU program to use it.  We
> are planning on moving coreutils' sparse traversal into gnulib (where it
> can be used by tar), as well as enhancing it to recognize Solaris'
> SEEK_HOLE, at which point, GNU tar should indeed be faster at
> recognizing already sparse files, and at which point you will indeed
> want a new tuning option that controls whether tar faithfully copies the
> existing holes of the source files (faster, but overlooks non-sparse
> blocks of 0s that could have been made sparse), vs. finding all runs of
> 0s (slower, done by current behavior, can result in a sparser copy than
> the original, and can still be made somewhat faster by skipping known
> holes).

The main problem with FIEMAP is that I could not find a useful description on 
it's behavior and that it seems to be higly compley without need. 

A problem with gnu coreutils is that it uses a restrictive license and for 
that reason, Tim Kientzle and I cannot use the code for our implementations. 
Do you have a short piece of example code for FIEMAP that returns hole/data 
pairs and that allows to detect sparse files?

http://www.fokus.fraunhofer.de/usr/schilling    ftp://ftp.berlios.de/pub/schily



reply via email to

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