Xref: utzoo comp.unix.questions:25622 comp.unix.sysv386:565
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!mcsun!ukc!stl!cel!ir
From: ir@cel.co.uk (ian reid)
Newsgroups: comp.unix.questions,comp.unix.sysv386
Subject: Reliability of System V 1K file system
Keywords: System V, reliability, file systems
Message-ID: <5869@suns302.cel.co.uk>
Date: 20 Sep 90 16:42:23 GMT
Organization: Crosfield Ltd., Hemel Hempstead, United Kingdom.
Lines: 62


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@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.
------------------------------------------------------------------------------