From: mark@acorn.co.uk (Mark Taunton)
Newsgroups: comp.sys.acorn
Subject: Re: Clever filesystems (Was Re: help! checkmap fails)
Date: 8 Apr 92 13:24:14 GMT
Organization: Acorn Computers Ltd, Cambridge, UK

I'm not sure who wrote which bits of the article posted by Malcolm
Lithgow.  I'll just reply to some of the points raised.  If UNIX and
UNIX filesystems bore you, you can stop reading now...


>In the interests of speed, UNIX has a buffer cache that stores potential
>reads, previous reads, and previous writes. The kernel also stores the
>super-block in core. The super-block contains an overall map of the FS,
>and is changed continuously. When a file system is mounted, the copy of
>the super-block *on disk* has it's 'dirty' flag set. If you attempt to
>mount a file system with this flag set, it will fail. So you have to run
>fsck (File System ChecK) to make sure the super-block and the actual File
>System match. 

This scheme is used in System V (at least SVR3.2, which is what I
checked, but probably for all System 5 filesystems): the "state" field
of the disc super-block can have various values, one of which is
FsACTIVE meaning that the filesystem is in use and that the data on
disc is not necessarily consistent.  What was not mentioned in
Malcolm's article was that when the filesystem is unmounted, after
forcing out all relevant data to the disc, the state field of the disc
superblock is reset to a value indicating that the filesystem is
"clean", thus allowing a subsequent mount to go ahead without an
intervening fsck.  In reality (i.e. in the face of possible software
bugs and less than perfect I/O hardware), this does not *guarantee*
that an fsck would give it a clean bill of health, but it's close
enough.  So if when you shut down a System V machine you unmount all
the discs first, there should be no need for any fsck after rebooting.
(I think the normal shutdown procedure does that automatically, but I
haven't used a SysV machine for quite a while, so I may be wrong
there).

For the BSD Fast File System (FFS), there is a field in the superblock
which, from its name - "fs_clean", and an associated comment in the
code, is apparently intended to serve a similar purpose.  However, in
4.3BSD (and in RISC iX), this field is simply not used; there is an
alternative way of signalling this information, as I outline below.

> If nothing much was happening when the system went down,
>they will match, but it will still take a *long* time to manage this. 

How long an fsck takes depends on how big the filesystem is, and also
how much it contains.  It also varies with the type of filesystem: the
Berkeley FFS (as used in RISC iX and many other modern UNIXes
including System V Release 4) has characteristics rather different
from earlier filesystems.  On BSD-based systems such as RISC iX,
checking a filesystem with only a few files is usually pretty quick.
Full filesystems are slower, but not desperately so: the 89MB main
partition on my R260, which has 6709 files on it and is 85% full,
takes around a minute to check.  That seems reasonable to me,
especially given that the machine is left switched on continuously and
usually only gets rebooted once in a couple of weeks, on average.

A key point which is not mentioned in the above comment "system went
down" is that there is a big difference between system crashes (which
are exceedingly rare in the RISC iX systems around here) and planned
shutdowns/reboots.  BSD (and hence RISC iX) has "fasthalt" and
"fastboot" commands which arrange that the filesystems are marked as
being clean (by the simple means of creating a file called "fastboot"
in the root directory), before the system halts.  When the system next
comes up, the presence of this file means that the filesystem checks
are skipped (and the file is then removed).  This is broadly
equivalent in effect to (though less selective than) the individual
filesystem state fields in System V.  If on the other hand the system
has crashed, the absence of /fastboot provokes an automatic run of
fsck.  Alternatively, the standard "boot" and "halt" commands do not
create the file and so allow deliberate execution of this step.

> If
>stuff was happening, then all sorts of problems occur, up to complete
>loss of you system. (UNIX has a lost+found directory so that fsck can put
>files with no directory entries for them (?) in there.)

I don't know much about more recent System V filesystems, but
certainly the earlier ones had less than ideal redundancy and it was
possible to lose quite a lot of data under fault conditions if the
machine was busy.  FFS has a significant amount of redundancy and I
have rarely lost more than a couple of recently written file blocks on
a system panic.  The worst case I have seen was where the disc
interface developed a fault and corrupted most data written.  Even
then, something like 90% of the disc contents (i.e. practically
everything written before the hardware fault occured) was successfully
recovered by fsck.  "Complete loss" of the filesystem is unheard of.

>This is one of the huge faults of UNIX as a desktop machine. Veritas
>fixes this. (And about time, too!) (BTW, the RS/6000 version of AIX also
>has a file system that fixes this, I'm not sure who else does.)

I'm not certain of the precise reference of "this" - if long fsck
times are considered a fault, then the mechanisms I have mentioned, to
avoid fsck on reboot in normal use, should answer the point.  If
filesystem recovery on system crashes is at issue, then the Berkeley
FFS is a sufficient improvement on the System V filesystem the author
seems to be familiar with, that all he needs to do is switch to a
system based on that (e.g. RISC iX ;-).  In any case, RISC iX (at
least) is now very reliable and very rarely crashes.

>I presume the R??? from Acorn suffers this problem?

Problem?  What problem?  :-).

>- Malcolm.

Mark.