SEEK_HOLE and SEEK_DATA support?

[jimd@starshine.org (Jim Dennis)]

 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.

 * (see http://blogs.sun.com/roller/page/bonwick?entry=seek_hole_and_seek_data
    for details)


 (Please feel free to cc me on any responses, or I'll pick them up via
 the archives and KT ... my account dropped off LKML years ago and I
 don't want to punish my poor old IDSL line with the traffic now)

-- 
Jim Dennis