Hi!

> Maybe with adding compression it could make a replacement for
> doublespace? (running it through the network redirector obviously)

Nope, doublespace compresses the actual data on your disk,
not the space which is free anyway ;-). I think it would be
nice to have a driver for one of those free / open compressed
embedded filesystems for DOS. Some ad-hoc suggestions for a
new filesystem:

Keep a normal FAT and boot sector and stuff, but wrap all the
access to the data clusters. For each data cluster, keep some
pointer to where it ACTUALLY starts (granularity: cluster, sector
or byte) and allow the clusters to be compressed. You would need
some offline "make compressed version of this filesystem" tool
and you would not be able to write to the filesystem later.
To get a relatively simple implementation, you can assume that
each cluster is separately compressed, for example with LZSS.
Then you only look at one cluster at a time for uncompressing.

Max amount of extra metadata: 32 bits per cluster. Note that
you do not store the size of the compressed cluster nor any
"this cluster is not compressed flag" - you can easily derive
those from the difference between this and next cluster start.

To reduce the space taken by the extra metadata, you can use
a more "granular" offset for the actual data location, and
you can compress the offset array by only storing the size of
each compressed cluster instead of its offset. To avoid too
much speed loss, you could still keep the offset of every Nth
cluster in some array in RAM to reduce the needed "counting".
You can even store the size of each compressed cluster in a
"granular" way, eg by saying that each compressed cluster has
to start at a sector boundary and thereby is a multiple of a
sector size in compressed size (ignore trailing garbage).

That way, you can get by with for example 1 byte of extra
metadata per cluster. Actually the whole "special tables for
compressed filesystem" stuff could be stored at the space
taken by the second FAT :-). Then a compressed filesystem
can not take more space than the uncompressed version even
in the worst case of "all filled with uncompressible files".

Just some inspiration for the compressed FAT FS dreamers :-D.

Eric



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to