Reliability of System V 1K file system
ian reid
ir at cel.co.uk
Fri Sep 21 02:42:23 AEST 1990
Forgive if this has been discussed before, but we have recently suffered a long
break in news at this site. My question is very simple, the reliability of the
System V 1K file system when a machine is subjected to a power cycle without
going through a proper shutdown sequence. Unfortunately on our system an UPS
is not an option (too price sensitive).
Our system is Interactive 386/ix 2.0.1.
What we observe is that occassionaly in the circumstances mentioned above, on
rebooting the system some indeterminate files have been corrupted and our
system will not boot in the way we expect. We boot up at run level 2 and
put our own files in /etc/rc2.d to tailor the behaviour of the system. None
of the files in /etc/rc2.d seems to be incorrect, or indeed any of the files
we load on the system (we also have our own inittab). We boot a kernel
on a floppy then mount the hard disk to determine this. Obviously our start up
performs an fsck on the file system if needed. The problem will occur even if
the machine has been idle for hours, and we have no cron jobs other than the
standard root etc ones supplied by Interactive.
In other lives I have seen similar problems on other System V based kit, so I
believe this to be a generic problem.
I know that System V uses a cacheing system for writing to disks, and that
the contents of this cache are flushed to the disk at intervals controlled
by a kernel parameter (at least in the case of SysVR3.2). The crucial data
structure is I believe the super-block which describes the organisation of the
disk. If the copy of this held on the disk ever becomes out of step with the
disk itself this can I believe cause the symptons I have described. But as
explained above this problem has been observed at a time when the disk contents
and thus the superblock should not be changing.
We are using a 40mb disk with a single / file system built using the default
paramters.
So my questions are:-
1) Do other people see this problem.
2) Are my comments (sketchy though they are) on the workings of the
file system correct?
3) How can we minimise, or alleviate it happening.
4) I have heard of file system hardening, which as I understand it was
something AT&T put into the kernel around the early days of
System V I believe to go some way towards reducing this problem.
Is this correct, and if so what exactly did it involve?
RTFMs, flames, email etc all welcomed. I will summarise if there is sufficient
interest but please note there is a long delay at our site.
------------------------------------------------------------------------------
Disclaimer: The opinions expressed are entirely my own, and not necessarily
those of Crosfield Electronics.
Name: Ian Reid. S-Mail: Peripheral Products,
R & D Department,
E-Mail: ir at cel.uucp Crosfield Electronics Ltd.,
or Three Cherry Trees Lane,
...mcvax!ukc!uk.co.cel!ir Hemel Hempstead,
Hertfordshire.
V-Mail: +44 442 230000 extn 3759 HP2 7RH
England.
------------------------------------------------------------------------------
More information about the Comp.unix.sysv386
mailing list