Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!uunet!ncrlnk!ncr-mpd!Chuck.Phillips
From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: File system fragility  Was: <none>
Message-ID: <CHUCK.PHILLIPS.90Sep12152731@halley.FtCollins.NCR.COM>
Date: 12 Sep 90 14:27:31 GMT
References: <6499@sugar.hackercorp.com> <1159@mpirbn.mpifr-bonn.mpg.de>
	<14260@cbmvax.commodore.com> <1990Sep8.050725.14384@zorch.SF-Bay.ORG>
	<1990Sep08.210559.19597@ecst.csuchico.edu>
	<CHUCK.PHILLIPS.90Sep9155105@halley.FtCollins.NCR.COM>
	<6900.26ebac61@jetson.u
Sender: uucp@ncr-mpd.FtCollins
Organization: NCR Microelectronics, Ft. Collins, CO
Lines: 72
In-reply-to: honp9@jetson.uh.edu's message of 10 Sep 90 20:08:16 GMT

>>>>> On 10 Sep 90 20:08:16 GMT, honp9@jetson.uh.edu (Jason L. Tibbitts III) said:
Jason> You've got a partial solution, which is read buffering.  Addbuffers
Jason> is OK, FACC II is better.

So is BlitzDisk.  (BTW, BlitzDisk allows a common pool of buffers to be
shared by all your floppies and hard disk partitions, unless you have a
HardFrame like I do.  Disclaimer: Just a mostly satisfied customer. :-)

Jason> But you still need the initial read of the data to get it buffered
Jason> in the first place.  How about: 	A program that, upon detection of
Jason> an inserted disk, allocates enough memory and starts reading data
Jason> during periods of inactivity.

Problem: How does it know _what_ to buffer?  If it buffers sectors 100-200,
but you ask for 1000-1500, it doesn't help.  In UN*X, most disk device
drivers "read ahead".  Your first access sees no benefit, but subsequent
sequential reads do.  More recently, "read ahead" has been implemented in
hardware on both controllers and on disk drives themselves.

Jason> There is a partial solution.  Here's another: 	A buffer program
Jason> that doesn't just buffer each sector, but the whole track as it is
Jason> read.

Good idea.  See above.  :-)

Jason> Let's think about this.  How can your locks survive a reboot?  A
Jason> power failure?

You got me.  Earlier in this thread I was told, by someone from C=, that
write locks _do_ survive a reboot and have assumed this to be true.  I
don't know the specifics of the implementation.

Jason> DO they really need to survive a reboot?

That's exactly my point.  I contend that write locks _should not_ survive a
reboot.  There are different ways to accomplish this.  fsck is one.
Removing write locks during validation is another.

Jason> I do quite a bit of 2400 baud downloading.  It takes over 10 hours
Jason> in some cases.  I've lost power many times.  Has there been problem
Jason> ONE with my HD?  Nope.  Just delete the zero length file and
Jason> continue.

(Sigh.)  _I_ suggested deleting the offending files at the beginning of
this thread.  Problem: _You have to know_ the names of the the
opened-for-writing files.  Works great for downloads or running programs
where you know what files were being written to.  However, a lot of
commercial and PD programs write to files without telling you (or otherwise
documenting) their names.

Jason> OK.  Fsck is needed, and I believe FixDisk does a pretty good job.
Jason> I prefer DiskSalv, but we want to fix the problem in place.

Jason> So we start with FixDisk.  What's wrong with it?  Well, it was made for
Jason> floppies, but won't work on large partitions.

Also:
2. It's not part of the OS.  (1.3 anyway)
3. _I_ don't have it.  :-)

Perhaps with a bit of tweaking FixDisk or DiskSalv _could be_ the AmigaOS
fsck.

Jason> ----====This is not written in the interest of flaming.
Jason> 			I simply want these ideas to mature====----

Ditto.
--
Chuck Phillips  MS440
NCR Microelectronics 			Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO.  80525   		uunet!ncrlnk!ncr-mpd!bach!chuckp