The return of SEEK_HOLE

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

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.