ir@cel.co.uk (ian reid) (12/06/90)
A long time ago I posted a question on the reliability of the SV1K file
system to the net, and promised a summary. Unfortunately the response
was underwhelming. Which is why this summary is so late. The thread lasted
five or six messages before going off at a noisy tangent discussing what was
and what wasn't a UPS.
In brief the question was why did my system lose files when a power loss
occurred. I can accept I would lose files which were being modified at the
time, but I was losing (or having corrupted) some indeterminate files
which made my system unbootable.
My configuration was running 386/ix 2.0.1, with a 40Mb disk attatched to a
ST506 controller, inside an Intel301Z box with 9126K extended memory.
I received a reply from Ed Hall <edhall%ives@rand.org> saying :-
I've run ISC's 2.0.1 for over a year, now, with assorted power
failures and crashes (I have a WD-1006SRV controller which locks up
every few weeks or so--a known problem between that model and several
UNIX's). I've never lost a file except for files which were being
updated during the crash--and even that occurance has been quite rare.
I received a reply from "LCDR Michael E. Dobson"
<rdc30med@nmrdc1.nmrdc.nnmc.navy.mil> saying:-
My system, an AT&T 3B2/600G running AT&T Sys V R 3.2.2 supposedly has a hardened
file system, however, I have had to restore from a boot floppy and tape on
occaision after a power failure. Because of this, in addition to an UPS, I
have installed a powerfailure monitor which automaticly begins the shutdown
sequence when it senses a powerfailure from the primary power source. The
UPS provides sufficient time for users to log off and for the sutdown sequnce to
complete. For a cost of ~$250 for the transducer/software, it's a very good
investment. E-mail if you want details on the product.
That was about it.
However around that time my newsfeed went down and I missed some messages
which were quoted as references in Michael's article. These apparently
according to Michael merely stated why the problem couldn't happen.
They may also have included an explanation of file system hardening which
would still be useful.
Apologies for the (very) late summary.
--
Ian Reid #include <std/disclaimer.h>
UUCP: ir@cel.uucp or ir@cel.co.uk or ...!{ukc,mcsun,uunet}!cel!ir
"Computers..proof positive that no-one yet understands how to describe any real
world situation in 0's and 1's."debra@svin02.info.win.tue.nl (Paul de Bra) (12/11/90)
In article <7454@suns302.cel.co.uk> ir@cel.co.uk (ian reid) writes: >In brief the question was why did my system lose files when a power loss >occurred. I can accept I would lose files which were being modified at the >time, but I was losing (or having corrupted) some indeterminate files >which made my system unbootable.... I have been running AT&T sVr3.2u for well over a year now and never ever lost files after a power-fail or panic (the panics were because i had a bad block in the swap space, not because of bugs in the os). This experience is with both the 1K and 2K file systems. There is a process which updates the disk in a more continuous fashion than the old /etc/update did. I have experimented with sVr4.0 version 2.0 and can only say that the ufs file system is horribly unreliable. Shortly after reading about 100 mbytes from a tape (but well after the time the automatic update program waits to write the stuff out to the disk) I got a panic, and fsck went on and on complaining about my file systems... I went back to sVr3.2. Apparently the sVr4.0 ufs file system doesn't get sync-ed properly by the automatic syncing deamon... Paul. (debra@research.att.com, debra@win.tue.nl)
james@bigtex.cactus.org (James Van Artsdalen) (12/11/90)
In <1630@svin02.info.win.tue.nl>, debra@svin02.info.win.tue.nl (Paul de Bra) wrote: > I have experimented with sVr4.0 version 2.0 and can only say that the > ufs file system is horribly unreliable. I recently converted my unix machine at work to our (Dell) SysVr4 product using a 650meg UFS (aka, BSD) file system. It's worked quite well for me. Since the conversion I have had only one panic, and raid.dell.com has been running on some pretty experimental hardware. That one panic came on a machine that had wires attached to #ADS and #RDY on the 386, and the wires might have touched something (or the wires may have been too long and killed the machine as the chips warmed up). I have run raid.dell.com on both 386 and 486 platforms. I have used TCP/IP quite a bit (and it's a substantial improvement over SysVr3), but have not tried NFS, RFS or X11r4 yet. > Apparently the sVr4.0 ufs file system doesn't get sync-ed properly > by the automatic syncing deamon... SysVr4 apparently has taken some steps backwards in syncing. NAUTOUP apparently isn't used even though it appears with the configuration parameters, and instead init(1m) does a sync(2) call periodically - a particularly inelegant solution. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789