Well, there's no demand specifically for SEEK_HOLE/SEEK_DATA[1] and the interface is ugly, so killing it before it spreads beyond Solaris seems like a good idea to me. OTOH, if you implement SEEK_HOLE/SEEK_DATA, nobody is going to bother using the good interface if SEEK_HOLE/ SEEK_DATA is the only portable interface. [1] The only user appears to be Joerg Schilling. http://www.google.com/codesearch?hl=en&q=+%5CWSEEK_(DATA%7CHOLE)&sa=N&as_case=y -- Nicholas Miell ...

I stand by my belief that SEEK_HOLE/SEEK_DATA is a lousy interface. It abuses the seek operation to become a query operation, it requires a total number of system calls proportional to the number holes+data and it isn't general enough for other similar uses (e.g. total number of contiguous extents, compressed extents, offline extents, extents currently shared with other inodes, extents embedded in the inode (tails), etc.) Something like the following would be much better: int ...

I didn't follow the discussion much, since it didn't appear to suit logfs too well. In a nutshell, logfs is purely block-based, prepends every block with a header, may compress blocks and packs them as tightly as possible (byte alignment). Maybe the "MAP" part fooled me to believe FIEMAP would also expose physical location of extends on the medium. But reading the proposal again, I am unsure about that part. If physical locations are exposed, SEEK_HOLE/SEEK_DATA is significantly more ...

Since it appears pathconf doesn't actually interface with the kernel I think that its not really worth chasing down. I don't think every fs maintainer is really going to want to chase down a glibc person in order to change what This was my interpretation of the man page, however Joern looked at what solaris Thanks much for your comments, Josef -

I have a few comments. Some of them are inline with the code. The one generic thing is that the Sun documentation specifically says to check pathconf(_PC_MIN_HOLE_SIZE) on the filesystem to see if it supports this request. Have you looked into adding this to the Linux version of pathconf? I haven't tried to look at the latest glibc, but 2.3.2 doesn't appear to have it. If we do have it, this request should really go to the kernel to ask the individual filesystem. However, it looks like ...