Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!ucbvax!pasteur!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: UnDelete & DiskSalv Question
Message-ID: <42225@sun.uucp>
Date: 17 Feb 88 17:52:29 GMT
References: <18956@aspvax.UUCP> <41962@sun.uucp> <3325@cbmvax.UUCP> <2908@swan.ulowell.edu>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 26

In article <2908@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes:
>steveb@cbmvax.UUCP (Steve Beats) wrote:
>>If the file was closer to the root than the current bitmap then the
>>chances are it will be zonked
>
>This isn't an issue on floppies, where the bitmap gets allocated at
>format & doesn't get deallocated, since there's only one.  

Uh Bob, if you look at where your floppy bitmap is on your floppy you
might be suprised to see that it moves around. I didn't believe this
until I watched it closely one day, the thing that fooled me was that
it trys to allocate a block near the root, which is right next to root
when it is formatted, when it builds a new bitmap it does the same thing
only now there are some directory entries nearby so it allocates a
block past them. Then on the next update it notices the old bitmap 
block is free so it uses it again. Basically, it ping pongs back and
forth. And when you fill up the disk (no free blocks) it won't write
out a new bitmap, it just leaves the flag saying the bitmap is invalid.
The validator will fix it up the next time it runs though. Same thing 
happens on hard disks as far as I can tell. Steve, does it still move on
FFS systems?


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.