pochron@cat51.cs.wisc.edu (David Pochron) (05/03/91)
If you are using the RRamDisk.lzh file (recoverable Ramdisk that allows up
to 32 units to be mounted, version 1.1) I would suggest you do some testing:
I was doing some testing to see what memory it used when allocating and
decided to do a diskcopy to one of the units I had mounted as a virtual
floppy drive RAM disk. When it finished, I checked all the files in the RAM
disk with FixDisk 1.2 and two of the files were trashed! After doing some
further checking with DiskX, I discovered the ramdisk.device seems to be
consistently erasing the first track (both sides) of the virtual floppy RAM
disk space! In other words, any files that used keys 2 through 21 were
always trashed because those tracks were getting cleared.
It didn't matter whether I used the FAST: device entry or the DISK:
device entry that came in the .lzh file mountlist - both lost data.
Varying the original mountlists that came in RRamDisk.lzh had no effect.
Doing normal file copies doesn't seem to cause a problem, but I have not
checked this thoroughly. Only diskcopying a disk loses data.
Again, if you are using RRamDisk right now I suggest you stop what you
are doing and (please!) do some tests by doing a diskcopy from a floppy
disk you know has a file that resides partially in keys 2 - 21 and then
run a disk checker program on the Ram disk or use a disk editor to make
sure there is still information in those keys.
It could be just my system, but I doubt it...I booted clean from an
untouched Workbench 1.3.2 diskette and used its diskcopy and mount to test
things out - same effect. My version of RRamDisk.lzh is 1.1; if there is a
later version, then this bug may not be present in it - but I haven't seen
a later version.
Since RRamDisk is hyped as "dynamic" (ie, it frees unused sectors) there may
be a bug in the routine that looks at the sector bitmap to see which sectors
are not in use.
One other thing - it seems to store a 0x00000001 in the "bitmap valid" field
of the root block instead of a -1 (0xFFFFFFFF) - FixDisk 1.2 complains about
this, and DOS always has to revalidate the RAM disk, and fixes it to a -1.
I will be switching back to VD0: and RAD: for now...A ram disk that loses
files is best not to be even touched!
--
David M. Pochron | Transparent DWV pipe: For the man who wants to
| see it all...
pochron@garfield.cs.wisc.edu | (If you don't know what DWV is, get a life! :-)aduncan@titan.trl.OZ.AU (Allan Duncan) (05/06/91)
From article <1991May3.063511.4135@daffy.cs.wisc.edu>, by pochron@cat51.cs.wisc.edu (David Pochron): ... > further checking with DiskX, I discovered the ramdisk.device seems to be > consistently erasing the first track (both sides) of the virtual floppy RAM > disk space! In other words, any files that used keys 2 through 21 were > always trashed because those tracks were getting cleared. > > It didn't matter whether I used the FAST: device entry or the DISK: > device entry that came in the .lzh file mountlist - both lost data. > > Varying the original mountlists that came in RRamDisk.lzh had no effect. Did that include setting reserved=22 ? To my understanding, this should leave the first 22 blocks unused (and hence unclobberable). This will stop trashing, but not raise confidence in the integrity of the program. Allan Duncan ACSnet a.duncan@trl.oz (+613) 541 6708 Internet a.duncan@trl.oz.au UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
aduncan@rhea.trl.OZ.AU (Allan Duncan) (05/06/91)
From article <1991May3.063511.4135@daffy.cs.wisc.edu>, by pochron@cat51.cs.wisc.edu (David Pochron): ... > further checking with DiskX, I discovered the ramdisk.device seems to be > consistently erasing the first track (both sides) of the virtual floppy RAM > disk space! In other words, any files that used keys 2 through 21 were > always trashed because those tracks were getting cleared. > > It didn't matter whether I used the FAST: device entry or the DISK: > device entry that came in the .lzh file mountlist - both lost data. > > Varying the original mountlists that came in RRamDisk.lzh had no effect. Did that include setting reserved=22 ? To my understanding, this should leave the first 22 blocks unused (and hence unclobberable). This will stop trashing, but not raise confidence in the integrity of the program. Allan Duncan ACSnet a.duncan@trl.oz (+613) 541 6708 Internet a.duncan@trl.oz.au UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
widyono@eniac.seas.upenn.edu (Daniel Widyono) (05/06/91)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Hi there. The subject is sort of related (I saw something that attracted my eye in a previous article on this thread). I'm having problems with my hard drive (actually, I had problems, now they're gone, but I still have this question): Once I was running Memacs, PSnap, and DNet all together. I was in the memacs screen, and tried to snap something on that screen to put into my Dnet window. It locked up, and the hard drive started flickering... then it wouldn't stop. So I did the three-finger nuke, and wound up with a requester: DH0 not validated. Next requester: Error validating: Key 8877 bad header type. Now, I saw in the previous article a mention of keys... How do I convert 8877 into a block or track? Or how do I find which file's header got messed up? System: Amiga 2000 40MB GVP HardCard 2MBout of8MB SupraRam Software: v2.10 I believe, Dnet v1.3 Memacs v1.0 PSnap Nico Francois Thanks, and if (as I've been prone to do) I didn't supply enough info., please tell me what else might be the problem. I'll send what I can... I'm leaving on the 10th, and packing my computer on the 8th. Dan Widyono BE '94 UPenn Life sucks.