Messages in this thread | | | Subject | Re: SEEK_HOLE and SEEK_DATA support? | From | Nicholas Miell <> | Date | Sat, 04 Mar 2006 20:18:37 -0800 |
| |
On Sat, 2006-03-04 at 19:05 -0800, Andrew Morton wrote: > 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. >
FIBMAP is a privileged operation.
-- Nicholas Miell <nmiell@comcast.net>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |