[Dave Hudson <dave@humbug.demon.co.uk> writes:]
>There's one prerequisite to all of this thinking - I believe that I'm right
>in thinking that it should be possible to create a filesystem within a file
>of another filesystem (a bit like stacker does under DOS). If I've got this
>wrong stop me now :-)
No, you have it right. Both bfs and vstafs have run on top of another
file. The big "gotcha" is that you have to make sure the server closes
before the underlying filesystem closes, otherwise the file data may not
be updated (and thus, your filesystem will be corrupt, since the underlying
server's "file data" is your filesystem structures!).
>1. Invent a new boot file system type - very simple, with limited if any
>subdirectory handling.
bfs. :-)
>2. Create utilities to make and repair the boot file system, where the fs
>can be made on a raw disk partition or a largish file of an existing fs.
bfs/cmd (mkfs, fsck is missing)
>3. Write a boot filesystem server.
bfs. Written. :-) A tarfs would be neat to have too, but if you're
more interested in the boot process than in writing a new filesystem,
bfs is already there.
>...
>5. Ensure that any shutdown utility checks that if our boot fs is really a
>file of another fs, that some defined action can be taken in the event that
>the boot fs file has been moved.
Um, not pretty. I've purposely set up all filesystems so that once your
system falls idle you can just power off. Dependencies on shutdown processes
make operating systems very fragile. This is not a fatal objection, more
below.
>C. The only thing we need to be able to do is determine where all of the
>sectors of the boot fs are, irrespective of whether it's a partition in its
>own right or whether it's a file in another fs.
This would be good to generalize, so that a single program could do the job
for any filesystem which cared to be supported. I'd use rstat(), but its
job is supposed to be done witha relatively modest amount of returned data--a
sector list could be enormous. A distinct filesystem operation would do.
What we do for the sync()'ing problem is add fsync() to our filesystems. Then
we have the filesystems fsync() their underlying "device" when they want to
make sure data is out to physical media. If it's running on another
filesystem, the filesystem writes out its blocks. If it's just a disk, the
fsync() is ignored (because the driver has already done the requested I/O).
This is desirable in general; I was planning on doing it before your boot
loader questions ever came up.
The logistics of placing the images into the boot filesystem are non-trivial.
If you're doing self-hosted builds, copying the files to /boot is easy enough.
If you're cross-compiling, you would need something like mtools, but for
bfs instead of DOS. If you're cross-compiling but booting the images on
another box, you'll have to deal with the two steps of copying over the
image, and adding it to the boot filesystem.
Editing boot.lst is easy for self-hosted builds (emacs /boot/boot.lst),
harder with mtools (emacs boot.lst ; bcp boot.lst /x/y/z/boot.lst), and
impossible if you don't have mtools. At worst, your scheme still allows
the current DOS-oriented boot process to be used.
The great advantage of your scheme, of course, is that the filesystem blocks
are much less likely to move around (and thus invalidate the precalculated
sectors the LILO-like loader keeps) than if you had to do it for each server
image. Or, if you did indeed assemble everything into a single boot image,
it still makes it far easier to deal with multiple versions of various
servers. Building under VSTa, the boot build is very convenient indeed.
All you do is edit and copy files as appropriate, with no follow-on programs
to recalculate sector locations.
Andy
Received on Mon Jan 10 10:38:52 1994
This archive was generated by hypermail 2.1.8 : Wed Sep 21 2005 - 21:01:53 PDT