Welcome, Guest. Please login or register.

Author Topic: damn checksum error on FFS partition!  (Read 2292 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline olsen

Re: damn checksum error on FFS partition!
« on: March 16, 2020, 12:40:29 PM »
wow ! so did that just & re-booted few times with no annoying checkum errors so looks like DiskDoctor actually did more than 'examining' ;D

No, the new Disk Doctor can only read from the partition, it will never write to it. This is baked into the design itself, as a precaution. The plan was to add a repair operation, but I still needed to figure out how to perform it, and which goals to follow.

If a reboot alone solved the problem then the cause may have been memory corruption, for example. When did you last verify that your RAM is in good working order? The simplest test involves copying as many files into the RAM disk until it either fills up or the system crashes. The RAM disk is particularly vulnerable to memory corruption and flaky DRAMs due to how it manages its data, which is why it (accidentally) makes for a "convenient" RAM test.
 
The following users thanked this post: klx300r

Offline olsen

Re: damn checksum error on FFS partition!
« Reply #1 on: March 17, 2020, 10:44:51 AM »
@ olsen
interesting info...the checksum errors on my system popped up after literally hours of transferring files from a CF card in the pcmcia port to a 32GB DOM in the onboard IDE port...I believed a small electricity interruption in my house stopped the transferring and that's when errors started popping up......

Sounds like the destination device may have been affected by the electricity hickup. If everything on the medium still looks OK, you'd be the lucky one :)

Quote
so the new DiskDoctor with OS3.1.4 only 'examines' hard drives so what to use then on drives larger than 4GB's nowadays to try to 'repair' issues ?

As of this writing I cannot recommend any tool for the job. The new Disk Doctor was supposed to be the tool which should solve the whole issue of multiple file systems, large storage devices and what have you. It's just that by the time the error detection and data recovery were finally coming together well, there was too little time left to wrap up the project with data repair included. Repairing an Amiga file system is hard because so much can go wrong.

In the mean time, what works would be to copy the data off your possibly corrupted volume to a different volume with Disk Doctor, then reformat your corrupted volume and copy everything back. Disk Doctor handles soft and hard links and will make a perfect file copy. Not that you'd want to bite that bullet unless you have to  :o

Still, it's helpful to have a known-good backup of the data you value and want to preserve.
 
The following users thanked this post: klx300r

Offline olsen

Re: damn checksum error on FFS partition!
« Reply #2 on: March 17, 2020, 10:57:57 AM »
so the new DiskDoctor with OS3.1.4 only 'examines' hard drives so what to use then on drives larger than 4GB's nowadays to try to 'repair' issues ?

SYS:System/Format - there are no tools around to "repair" a broken "modern" FFS.

DiskDoctor is not a good name, it doesn't by any means "doctor" disks, a more describing name would be "FFSDump", as that is all it does - dump the content of a broken FastFileSystem.

The new Disk Doctor can both find and report defects as well as recovering data from the volume, with various options to restrict the set of directories, files and links which you want to keep. The recovery operation preserves all file attributes (date, owner, protection, comment) and will reproduce both soft and hard links (if possible; if the target for the hard link is not copied you won't get the link). It spends far more effort on the task than dumping what it finds on the source volume.

My ambition still is to go beyond the examine/copy operation, which all by themselves turned out to be far more complex than I had anticipated. The learning process was painful and it colours how a possible repair operation would have to work.

Disk Doctor is arguably a poor name, especially in the light that a medical doctor's duty is so different from what, by analogy, the original Workbench 1.2/1.3 Disk Doctor did. For one thing, destructive changes made to the disk contents should require the user's informed consent, but the 1.2/1.3 Disk Doctor never went that far. It just did its best to make a presumably damaged disk accessible to normal file system operations again. It was recommended that when the 1.2/1.3 was "finished" with a disk, that its contents should be copied to a known-good disk and the disk whence the contents came from should be reformatted. The 1.2/1.3 Disk Doctor was expected to make irreversible changes with negative impact to the disk.

Keeping the name "Disk Doctor" was to make a point of how to properly do the kind of job which the original tool was not designed to handle well. You should be in control of what Disk Doctor does, and you should be informed about the choices you have when you are looking at a possibly damaged volume and want to recover its data. It's uncommon but not wrong to try and apply medical ethics to data recovery.

Quote
I wish there was ways to prevent the built in validator from starting, as it often crash for various reasons (low memory situations etc), and just allow _manual_ optimistic read-only mounting of FFS also when running AmigaOS (and not just when running NetBSD or Linux...)

Only write-protecting a volume will keep the validation process from starting. Back in the day when the Disk-Validator was separate from the ROM file system you could prevent it from becoming active by removing it from the boot volume.

Most storage media is auto-mounted and cannot be made to appear write-protected. This is an unsolved problem which is not supposed to happen.
« Last Edit: March 17, 2020, 11:02:23 AM by olsen »
 
The following users thanked this post: klx300r

Offline olsen

Re: damn checksum error on FFS partition!
« Reply #3 on: March 19, 2020, 10:34:06 AM »
HDToolBox (RDB) and Early-startup could allow setting partitions read-only, or "non-validate".

Thank you! I can see how this would be made to work.

To begin with, we could use the file system control flags which were introduced with AmigaOS 3.1.4. Currently, the FFS uses such control flags to enable/disable TD64/NSD64 support on demand. There should be another flag bit available which would indicate that the volume should be mounted read-only.

That feature would (initially) be supported by the FFS only. Upon startup, it could check that flag bit and pretend for the time being that the mass storage medium is write-protected. If you wanted to revert to how things really are (not write-protected), the DiskChange command could do that.

The "mount as read-only" option should (initially) find its place in the early startup menu.