| |||||||||||||
The return of SEEK_HOLEThe return of SEEK_HOLEPosted Apr 30, 2011 3:29 UTC (Sat) by dlang (✭ supporter ✭, #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.
(Log in to post comments)
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.
|
|||||||||||||