Reliability of System V 1K file system

Conor P. Cahill cpcahil at virtech.uucp
Fri Sep 21 23:15:18 AEST 1990


In article <5869 at suns302.cel.co.uk> ir at cel.co.uk (ian reid) writes:
>We are using a 40mb disk with a single / file system built using the default
>paramters.

Your problems would probably diminish if you had a root file system that
was fairly stable (i.e. no user files being created/deleted there).  You 
can do this by creating additional partitions and moving your news stuff 
to the other partition.

The big problem with power loss is that it may be doing things to your
system that no OS could protect against.  For example, at the point of
power loss the disk controller may be dumping junk information to different
parts of your disk.  I'm not saying that this is happening, just saying
that it could.  The loss of power to a system (especially from a provider
loss which can include all kinds of yucky power things like spikes) is
a very bad thing for a system.

>	1) Do other people see this problem.

We originaly ran our 386/ix systems with no protection (other than the  
standard surge protection) and had several power losses (usually around
two to three a month) without experiencing the problems that you describe.

>	2) Are my comments (sketchy though they are) on the workings of the
>	   file system correct?

Split you filesystems so that root and /usr are both as small as they
have to be and have little or no user data on them (i.e. create yet another
partition for your user data (total of three)).

>	3) How can we minimise, or alleviate it happening.

Get a UPS.  Ensure that you have a good surge protector.

>	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?

File system hardening involves an ordered updating of the information 
related to file system changes which should make it harder for fs corruption
to occur. 


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 



More information about the Comp.unix.sysv386 mailing list