The return of SEEK_HOLE

Posted Apr 30, 2011 3:16 UTC (Sat) by jrn (subscriber, #64214)
In reply to: The return of SEEK_HOLE by dlang
Parent article: The return of SEEK_HOLE

> so this seems to be implying that this isn't just reporting what holes currently exist, but holes that could potentially exist

I think you're misreading it.

This is about reporting holes, but nobody wanted to guarantee that such a thing as a hole exists. So the semantics are: if SEEK_HOLE reports a hole, the content there consists of NUL bytes. That's it (though naturally enough any sane kernel is only going to report large blocks of NUL bytes, for example by reporting the actual holes, and userspace programs are likely to rely on that assumption for reasonable performance).

The return of SEEK_HOLE

Posted Apr 30, 2011 3:29 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

the question is the defintion of 'large blocks'

what may be a large block for a filesystem running on one device may not be a large block for another device.

I'm not saying that it makes sense to have it report down to every single null byte in the file, but I do think that there should be some ability to define what 'large block' means outside of editing the source.

The return of SEEK_HOLE

Posted Apr 30, 2011 19:10 UTC (Sat) by jrn (subscriber, #64214) [Link]

I think I'm missing something. I'll repeat what I already said and you can tell me where I go wrong. The "large blocks" is a consequence of an implementation that doesn't care about the size of blocks. It just reports holes.

Perhaps you're talking about the holes feature in general, and saying that users or applications should be able to configure when a seek while writing will create a hole? Then I would understand a little better.