Combuster wrote:
By reading the specs, the only reason to take on SFS is because its public domain - for the rest its close to FAT32 with all its disadvantages and none of its advantages:
Well, the point in creating a Simple File System is to KISS,
It does not even try to become something like FAT, which could be used for rather large - 2 GiB - hard drives. It is basically thought for small media like floppies and especially small boot partitions where the data does not change for long spans of time.
By the way, it does not have one of FAT32's disadvantages: it is not patented by Microsoft.
Combuster wrote:
basically theres no support for fragmentation: i.e. unless your file is one block big you can have 50% free space and not be able to store it without having to defragment first.
There is
yet no support for fragmentation in SFS
1.0 draft. You also can collaborate! If you devise an algorithm that allows SFS to accept fragmented files while still remaining Simple, and want to contribute it to the public domain or whatever free license SFS ends with, propose it!
On the other side, given the use that SFS is going to have (floppies and boot media), I don't see a really big problem with that. SFS defragmentation (whats the name? compaction?) seems a very simple operation to me.
Combuster wrote:
As for directories, speed is terrible finding one directory's contents - you'll always have to run over the entire index. That and the redundancy in filenames makes it a horror to work with directories
I also can't see a problem with going through the whole index area - for small media. I do think that the entries are a bit bloated: 64 bytes that could be reduced to 48 by trimming the file start & end block and size from 8 bytes to 4 (Are you really storing a >4GiB DVD image in a 1.38MiB floppy? I totally NEED your compressor!!) and reducing the entry name bytes by 4 (for file entries; in others all 16 could be taken from "name" or "unused"). But even with this bloat, an index area with 256 entries (let's say the source of your microkernel) would be roughly 16KiB, or about 2% of a 1.38MiB floppy. Not too much for a filesystem easy as hell to parse: you can even keep the whole index in memory. And remember that this index area can be expanded (and, I would propose, shrinked were it needed and possible).
About directory redundancy: I agree with you in this matter. If I haven't misunderstood the discussions in the original thread, the point of having the full path name in the file name was to avoid directory entries completely. However, someone pointed this scheme would not be able to represent empty directories, and their entries were added, but the full paths stayed. I can think of several ways to address this:
- Remove directory entries and keep full paths. Empty directories are represented by file entries either with their name and a trailing slash (so the entry for folder a/b/c is "a/b/c/") or by a phony entry with a special name in that directory. This brings a new problem: when creating a new file into an empty directory, its entry must be removed, and vice versa when removing the last file of a folder.
- Keep folder entries and remove full paths. The index of the parent directory entry of a file or folder is stored in a 4 byte field (again, I think that 4 billion entries is enough: FAT16 allows 65k files, while FAT32's max is 268 million). Files or directories in the root point to entry #0. I can't see any problem with this solution, so it is the one I would prefer to be included.
Oh, and for the record: I think that, for boot time processing, having to read just through an index area of files with a full path is WAY simpler than of jumping through the directory tables in the data area of FAT. This is the only use I can see for full paths, but even my second proposal can be implemented in assembly without too much hassle. If you are searching for, say, /System/Boot/Kernel.sys, you just look throughout the index area for a file named "Kernel.sys". Then you jump to its parent directory (you know its entry #, you know the entry size, so you know the location) and check whether it is a folder named "Boot", and so recursively. If a check fails, you return to whichever entry you were and continue searching for "Kernel.sys"
Combuster wrote:
Apart from that, SFS is the perfect fs for those wanting to have something easy without worrying about complex algorithms, and not have windoze mess with it. definately a good experiment for newbs on the subject.
That was the whole point, I think ;D
