Mail Archives: cygwin/2003/05/20/13:16:41
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/
- Raw text -