Hi,
BenLunt wrote:
From my brief study, this looks to be, in general, a one-time write file system. i.e.: You already have the files on a host media system, then wish to transport them to a different media system via this file system, and not much more. Most likely the idea of the author, and it should be.
It's not quite "one time write" (although that's one of the main use cases). In general; when the file system is mounted software would scan the index area and (in conjunction with the super-block) figure out which blocks are in use and which are free from that (e.g. initialise its own internal "1 used/free bit per block" bitmap); and possibly also cache some or all of the index area. Once that's done it's easy to add new files to an existing file system; delete files/directories and reduce a file's size.
The lack of (file data) fragmentation means that it's not easy/cheap to append data to the end of a file - unless you're very lucky you'd have to make space (either by treating it like "creating new file then delete old file", or by moving other files out of the way).
For (free space) de-fragmentation you'd do "compaction" (shift data to lower or higher block numbers to eliminate gaps) for both file data and the index area. This isn't nice either (for performance you'd want to cache at least parts of the index area in memory); and it might be better to just copy all files elsewhere (e.g. a "/tmp" directory on the OS's native file system), wipe everything (fill index area with "unused entries"), then copy all the files back.
BenLunt wrote:
It doesn't really explain the use of directories. As far as I can tell, when a Directory Entry is found in the Index area, all File Entries that follow are to be within that named directory until another Directory Entry is found. i.e.: only the Index table knows of directories. This seems to be a good practice, for this file system, until a Deleted Directory Entry is found.
Now, again, since this file system seems to be a one-time write file system, a Deleted Directory Entry is not very likely. However, what does happen if one is found? Are all following Entries assumed to be deleted until the next non-deleted Directory Entry?
I'd assume that you'd normally delete all the files within a directory before deleting the directory. If a (non-deleted) file exists within a deleted directory or there is no directory entry at all; then the file system is "corrupt" and you'd recover by making an assumption - either assume the directory shouldn't be marked as deleted or should exist and fix/create the directory's index area entry; or assume the files should be deleted or shouldn't exist and remove them. I'd probably do the former (unless you can ask the user what they want done).
Note: The earliest draft didn't have directory entries - directories were simply assumed to exist where necessary (e.g. an entry for the file "/foo/bar/baz.txt" implies that the directory "foo" exists and that the directory "foo/bar" exists). I can't remember exactly why they were added (so you can have empty directories and/or timestamps for directories?).
BenLunt wrote:
Also, if I store, for example, 10 files within the root directory (no Directory Entry has been found yet), then store a Directory Entry with a number of Entries within it, how do I get back to the root? Simply a new Directory Entry of '\' or '/' which ever is used, then any entry that follows is to be in the root until another Directory Entry is found? Or is it assumed that you will never need to be back to the root, since it is considered a one-time write and you should have already written everything to the root.
Given the string "foo/bar/baz.txt"; delete characters from the end of the string until you delete a path separator character or there's no characters left. The first time you do this you'll get the string "foo/bar" (the parent directory's name). Do it again and you get "foo" (the grandparent's name); and do it some more and you get an empty string (the root directory's name).
Once you've obtained a directory name string; to find the corresponding entry (in the index area) you'd search the index area (if you didn't cache some or all of it or build a hash table or something when you mounted the file system).
BenLunt wrote:
Anyway, my curiosity got me and I had to study it a little. As a one-time write file system, it does seem to be quite simple and elegant. It could be used quite easily for transporting files from one host to another. I think though, and again I am not criticizing in any way, that once it is used for anything other than a one-time write file system, problems would start to arise. However, I think that it was meant to be a one-time write file system, so these problems are not to be expected.
Yes - it was mostly intended for transferring files between computers (on relatively small devices - e.g. floppies and small USB flash devices), where the normal use case is "format/wipe, copy/create files, move it to a different computer, read files"; which is why there's no file permissions (they don't make sense for this use case), no fault tolerance (just create a new copy from wherever files originally came from if something went wrong), no file data fragmentation (not worth worrying about), etc.
Cheers,
Brendan