This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SPARSE files considered harmful - please revert


On Tue, May 20, 2003 at 11:01:08AM -0400, Rolf Campbell wrote:
>Christopher Faylor wrote:
>>On Mon, May 19, 2003 at 07:27:06PM -0400, Bill C. Riemers wrote:
>>
>>>>I think you need to read the documentation a little more closely.  
>>>>Either that
>>>>or provide references to the parts of the documentation that says that
>>>>normal RW operations would fragment a sparse file.
>>>
>>>It is rather obvious.  Let say you have three blocks worth of data, and
>>>is written into a file with a physical block followed by a sparse block
>>>followed by a physical block.  No disk space is reserved for the sparse
>>>block.  Why should it be, as it would defeat the whole purpose of using
>>>sparse files?  So physically on disk you have two consecutive physical
>>>blocks.  What then happens if you open the file in RW mode, seek to the
>>>sparse block and write some data?
>>
>>
>>1) You are assuming behavior that isn't documented.  I can imagine that
>>the first block could occupy, say 16 blocks and depending on the size of
>>the hole, there could be no fragmentation.
>A agree that he is making an assumption, but he is probably right.  Even 
>if 16 blocks are reserved for adding intermediate blocks, you would 
>still end up with out-of-order blocks in the file; which isn't as bad as 
>real fragmentation, but isn't as good as all blocks in order.

No, you wouldn't.  If you allocate a block, skip 4 blocks, write a
block, go back to the begining, skip a block and write a new block, I
would not be surprised to see that there is no fragmentation.

You would end up with a potential gap in the middle of the file but that
isn't necessarily even a bad thing given rotational latency.  It's not as
simple as saying "there's a gap so it must be bad".

As usual, however, this discussion is really not worth the effort that
goes into it given the number of sparse files out there.

>>3) What no one seems to be mentioning is that we are trying to emulate
>>UNIX behavior here.  If the above is an issue for Windows then it could
>>also be an issue for UNIX.
>
>And it is.

So there goes your argument.  You can't argue that you want cygwin to
behave differently from unix and really win.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]