Re: SEEK_HOLE and SEEK_DATA support?

[Andrew Morton <akpm@osdl.org>]

jimd@starshine.org (Jim Dennis) wrote:
>
> 
>  All,
> 
>  Has there been any thought about adding SEEK_HOLE and SEEK_DATA (*)
>  support to Linux?  
> 
>  I ask primarily because of the interplay between 64-bit systems and
>  things like /var/log/lastlog (which appears as a 1.2TiB file due to
>  the nfsnobody UID of 4294967294).
> 
>  (I'm realize that adding support for these additional seek() flags
>  wouldn't solve the problem ... archiving tools would still have to
>  implement it.  And I can also hear the argument that Red Hat and other
>  distributions should re-implement lastlog handling to use a more modern
>  and efficient hashing/index format and perhaps that they should set
>  nfsnobody to "-1" ... I'd be curious if those details are driven by
>  some published standard or if they are artifacts of porting.  I'd also
>  be curious what's happened with other 64-bit UNIX ports and whether
>  this issue ever came up in Linux ports to the Alpha or other 64-bit
>  processors).
> 
>  As a stray data point I just did a quick experiment and just doing
>  a time cat /var/log/lastlog > /dev/null took about:
> 
>  36.33user 2453.99system 41:35.90elapsed 99%CPU 
>     (0avgtext+0avgdata 0maxresident)k
>     0inputs+0outputs (133major+15minor)pagefaults 0swaps
> 
> 
>  On an otherwise idle 2GHz dual Opteron (yes, of course the extra
>  CPU is wasted for this job), reading SCSI disk hanging off a Fusion MPT 
>  controller.
> 
>  From what I hear our Networker processes pore over these NULs for about
>  two hours any time someone fails to exclude /var/log/lastlog from their
>  backup list.

This can already be solved in userspace (and I'm sure it already has been
in some backup programs).  Use the FIBMAP ioctl() against the fd to find
out whether a particular block in the file is actually instantiated.

Not all filesystems necessarily implement FIBMAP, so one would need to fall
back to sucky mode if FIBMAP failed.