Message-Id: Date: Sat, 19 Apr 97 14:32 NZST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: alaric AT abwillms DOT demon DOT co DOT uk From: Lorier Subject: FileSystems & Fragmentation. Cc: Matthias DOT Paul AT post DOT rwth-aachen DOT de, opendos-developer AT delorie DOT com Precedence: bulk >> >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.