boot fs update

I've mentioned some of this to Andy earlier today and he suggested sending
a development summary to the list (in case you're interested).

I've finally managed to get a hour to complete the first pass at a modified
bfs :-) The code now allows me create a boot fs, mount it and use it (all
tested on top of a dosfs).

The inode handling has been completely revamped so that when the server is
run it takes a very simple set of details from the valid directory entries
(with only 128 entries this isn't exactly time consuming) and creates a copy
in memory of the details and puts links from neighbouring files (forwards
and backwards). Each node in the list of allocated files (ie a file that
has at least one block allocated) is responsible for managing any space that
may be generated immediately after itself and before its neighbour (or the
end of the fs in the case of the last file). The root inode is in this list
so that it can catch any blocks that are freed up by deleting files
immediately adjacent to it. My idea here is that no unmanaged holes can
appear in the fs and that if a file wishes to expand it simply looks at
whether there's enough free space between it and it's nearest neighbour
(this makes block management very simple).

What I've been thinking is that in the event of there not being enough space
adjacent to the file it should be possible to try and do something simple to
make space rather than have to compact the whole fs (eg grab space off a
neighbouring file), but this is an optimisation for the moment - my next
task is bfsck (file system checker) and bfspack (file system compaction
proggy).

If there are any comments on what I've done/am propsing to do I'd be
grateful for them (the only fs work I've done before was writing mkdosfs for
Linux - and this only involves writing a boot parameter block, an empty FAT
table and an empty root directory - which was much simpler!)

Once I complete the bfs utils I want to test bfs on a physical partition
instead of on top of dos - has anything been done to generate a library
version of fdisk.[ch] (as used in the scsi and wd code)? If not it would
seem to make sense for me to generate a library version of this and modify
wd to use this (so I can include the bfs ID field).

From this point I need to modify my floppy bootstrap/setup routine so that
instead of just reading one prebuilt file it will do the building itself.
This may take a week or two (depending on how much I need to do for my real
job). This bootstrap code currently uses the Linux as86/ld86 real mode
assembler and linker (written by Bruce Evans). I'll be porting this code
(plus a few new patches Bruce sent me to VSTa this weekend with any luck.

I'd anticipate that there'll be a whole series of enhancements to this basic
boot code over the next few months, but the first version should make it
possible to boot VSTa without using DOS.

                Regards,
                Dave
Received on Wed Feb 23 16:48:31 1994