SFSSalv recovery speed

[nOw2]

Hi,

SFS has corrupted a partition on a SCSI disk attached to a CyberstormPPC. The partition is 28GB (but not full) and contains ~350,000 files.

SFSSalv seems to be working, but is slow. The current status:

1. It took about 12 hours to get to the point where I could select files to recover. All files came up okay, no "--BAD--" directories, so this looks good. RAM usage was around 95% - 2MB free from 64MB. CPU usage was high also.
2. Clicking "Select All, Recursively" took several hours to respond, but did.
3. Finally, it's now recovering files. It's been doing this for 12 hours:
- It has created the directory structure on the target disk.
- The target disk had 15.1MB in use last night.
- 8 hours later, 15.5MB is in use.
- The source SCSI disk is active and the heads can be heard thrashing.
- Memory usage is still high, 2MB free.
- SFSSalv is using lots of CPU.

So, the question would be is this normal? I'm going to leave the Amiga sit there until something happens, but can I expect SFSSalv to complete?

[paul1981]

I've never had to use SFSSalv before. All I can think of is to make sure that the corrupted partition has plenty of disk buffers (1000+).
I'd be interested to know how it's become corrupted though. Does it even mount? What were you doing at the time of corruption?
Anyway, hope it speeds up a bit for you...
Maybe you could e-mail the author? He may be able to answer your question.

[nOw2]

I've had to use it many, many times... In this case, the machine locked up and on reboot one partition was corrupt. I would have restored from my backup IDE disk, but that was itself corrupted in a similar way back in 2008 and I gave up on it back then.

I've just increased cache with SetCache (1MB of RAM remaining...) but that's had no effect. AddBuffers won't work on a Non-DOS disk.

I suspect I know what is happening as I noticed that it is working, just at a rate of maybe 1 file per hour (that's 40 years to salvage the files). It seems to have a slow file list implementation which it is recursing for each file recovered. That would match what happened when scanning the disk and again when selecting files in the GUI. Has the source been released for SFSSalv? I'm very motivated to fix this.

I may try again and see if I can salvage a smaller number of files, and do that in batches.

I wouldn't know which author to email.

UPDATE:

I think I've got it!
1. I installed the latest SmartFileSystem and SFSSalv - I was quite a few versions behind.
2. Freed up the absolute maximum of memory.
3. That got SFSSalv to start up quicker - only 30-60 minutes to get past "Checking BNDC".
4. I selected a limited number of files. The select process still took about 5 minutes until the GUI became responsive again.
5. Clicked undeleted, and the files are coming out! It's slow, but no huge obvious delays between files.

There's probably still another day's work for me here but it's working. I'd definitely like to see the SFSSalv sources as I'd like to improve its memory and speed performance.
Also, I'll definitely get the backups working again.
And I'll be giving PFS3 a go too, I think.

[paul1981]

I've had to use it many, many times... In this case, the machine locked up and on reboot one partition was corrupt.

Sounds like the machine was locking up due to an upset filesystem in some way, being as though after lockup you get filesystem corruption. This should never happen. Maybe the new version will fix this for you, but I suspect something else is playing a part here.

[nOw2]

I've had SFS randomly corrupt partitions on at least three different machines throughout the years, though on another it's run fine and continuously for probably 10 years straight.

I agree there may be something wrong with this machine - it has indeed been extremely unreliable since around 2004(!) which is when the PSU started to fail, I've finally installed a new ATX PSU this week which cured that but I still had two lockups over the last few days.

I don't know what the root cause is but SFS has had its last chance here on my A4000T - the recovery disk is already formatted as PFS3. No file system should go NDOS out of the blue like that, and finding that SFSSalv hits a usability ceiling around the 10GB / 100,000 file mark is the final straw.

I will however upgrade my other machines with the newer SFS release from 2007. I'm not reformatting a working machine :-)

[nOw2]

Quick update on this: I'm afraid I gave up. SFSSalv would being recovering files, but after a while the recovery would halt. The disk light on the source would flash, CPU usage still high, but nothing on the destination disk for hours. I tried several source directories, and while some small ones were recovered I couldn't get the rest of the data.

Format and start again. I have lost data that was unique to that machine, but can get a reasonable install back by cloning another 4000 onto the disks.

[nOw2]

I'm going to threadjack myself.

I've been hit by a horrific coincidence. The machine I mentioned above, which runs SFS without error for year after year? It just lost its Work: partition.

It's a WinUAE machine running on a Linux VMWare host. The host was rebooted and the UAE machine failed to boot up after. The partition was not NDOS but instead locked the machine up when writing to it. sfscheck confirmed the presence of errors.

I was able to restore a month-old backup (of the entire hard-file) in this case.

I hadn't touched the Amiga side, at all! However upgrading SFS will be the first task now it's back up and running.

UPDATE:
Was already on SFS 1.279.

[itix]

There are couple of bugs in 68k SFS that can corrupt it. If there are two simultaneous file writes in progress and you reboot machine (or it locks up or crashes for whatever reason) you may end up with a corrupted filesystem.

To recover files from your SFS partition you could try to find MorphOS user to try SFSDoctor for your HD. It can repair SFS volumes and its file recovery is faster.

[nOw2]

The A4000T did run MorphOS 1.x when that was first released. I guess an option would have been to reinstall that and give SFSDoctor a go, if it runs on 1.x.
My current MorphOS machine is a Mac Mini, so UWSCSI was no-go there.