Re: SEEK_HOLE and SEEK_DATA

[Szakacsits Szabolcs <szaka@sienet.hu>]

On Fri, 3 Feb 2006, Bryan Henderson wrote:

> It isn't obvious to me that a series of seek/tell are noticeably slower 
> when copying a file than a single system call that returns a list.

It depends on how fast one is able to copy.

A special but not so unusual case of this if one doesn't want to copy at 
all and just interested in querying this information for analyses, future 
decisions, etc. Then the numbers would be something like this for e.g. a 
200 GB sparse file:

  JFS  + FIBMAP      	   137.80 sec  97% CPU
  XFS  + FIBMAP            117.81 sec  97% CPU
  ext3 + FIBMAP             88.40 sec  96% CPU
  XFS  + XFS_IOC_GETBMAPX    0.05 sec  95% CPU

SEEK_HOLE/SEEK_DATA is somewhere between XFS_IOC_GETBMAPX and FIBMAP, in 
the worst case half-way.

> I usually prefer a special version of read() that shows you holes 
> explicitly to either of the other approaches, but SEEK_HOLE/SEEK_DATA has 
> the definite advantage of being a smaller perturbance of the API and 
> easier to understand.

Absolutely. For the price being less useful and efficient.
  
	Szaka