On Mon, Dec 30, 2013 at 10:18:31PM +0100, Jan Kara wrote: > > IIRC with the generic implementation we treat everything <= i_size > > as data and i_size as the first hole. The way the spec works is > > that if we are currently at data and do seek_data then we just > > return our current offset, same for a hole. In order to not be a > > jackass and have -EOPNOTSUPP for anybody who didn't implement > > seek_hole/seek_data I just did it this way where the only hole is > > the one that starts at i_size, so seek_data before that is going to > > return the value. > > Correct. My point is that I actually don't see anything 'jackass' in > returning -EOPNOTSUPP. In fact, one useful reason in returning -EOPNOTSUPP is so the userspace program can tell whether or not SEEK_HOLE/SEEK_DATA is really implemented by the low-level file system. If the userspace program knows that it's not available, it might want to fall back to some alternate mechanism, such as scanning the contents of the file blocks which are all zeros. (If the program knows that SEEK_HOLE/SEEK_DATA is really there, it might to avoid the CPU overhead of scanning the data buffers as it does the copy.) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
