Mail Archives: opendos/1997/04/18/22:36:12
>> >An extent based filer like VSTa uses or, I deduce, NTFS is (it uses
>> >512 byte allocation units) can be more efficient, I think; disk
>> >space is managed like malloc allocates blocks of RAM, in runs of
>> >sectors. Unless it gets really fragmented, this is smaller than having
>> >free-space bitmaps and indirection blocks and all that. And smaller
>> >means faster, no? :-)
>
>> Er, not always :) It's usually a trade off between Speed and Size, having to
>> do it that way means you have to do mass calculations, and also trying to
>> handle adding to to the end of a file is a problem if the next file is right
>> at the end, thus leading to high fragmentation :)
>
>To extend a file, just increment that extent's length counter until you reach
>the next extent, then start with a fresh extent. Easy peasy?!?!?
Yeah, but allowing one cluster to house two (or more) files adds complexity
I don't think you'd want :)
>Fragmentation can be solved by moving fragmented files (found when the filer
>notes that accessing a certain file has entailed a lot of extent seeks)
>into contiguous areas from time to time, a sort of background defrag that
>works on individual files when it feels the need.
It would be nicer just to have a file system that doesn't require defraging.
If OpenDos/32 was Multithreaded then having a low priority thread to slowly
defrag files that are badly fragmented would be nice.
- Raw text -