Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: koshman on September 24, 2010, 03:30:34 PM
-
As I discussed in a different thread I recently changed all my partitions back to FFS (previously PFS3). Yesterday when I was loading them up with games and stuff under WinUAE I accidentally hit the Power button on my keyboard, which among other things resulted in unclean WinUAE shutdown during copying files from a PC HDD to Amiga CF. After that when trying to resume the process I was surprised by numerous "disk not validated" errors and because I didn't know of any other solution I reformatted the affected partition. Later it happened to me again on a different partition without an obvious cause.
My question is - is it neccessary to reformat the partition when this happens or is there another solution? If it is, is quick format enough? And also is SFS or PFS3 better at handling such issues (some kind of autorecovery?).
I don't care much about the speed of the filesystem right now, but reliability is of the highest priority.
-
This is why power buttons on keyboards is a bad design idea! :)
Invalidation usually isn't anything serious - just leave the system alone for a while and it will usually resolve itself. It happens if there's disk activity during a crash, reboot, or power cycle.* I've never lost data from an invalidated partition (except maybe the destination file being written to during the crash).
When you start getting "Checksum error on block ", that is when you need to start thinking about reformatting. But those errors are rarely related to validation and usually indicate some other problem.
* And I suspect this is why the Suspend/Reboot requesters always tell you to wait for disk activity to finish
-
Yeah, I totally agree about the buttons, but I haven't seen a cheap keyboard without them lately. These accidental shutdowns happen to me regularly about twice a month and I'm sure next time the keyboard will die a horrible death as my patience runs out...
Regarding the filesystem - I'm currently away from home and won't be able to check for sure till tomorrow, but I fear that I also saw some checksum errors following the shutdown.
As for my previous question - is it possible that a more advanced filesystem (either PFS3 or SFS) would be less affected/able to recover in this kind of situation (power down during writing)? I've been using PFS3 for the past year and this hasn't happened to me during that time (although I can't remember ever having copying inerrupted in this way).
Thanks.
-
As for my previous question - is it possible that a more advanced filesystem (either PFS3 or SFS) would be less affected/able to recover in this kind of situation (power down during writing)? I've been using PFS3 for the past year and this hasn't happened to me during that time (although I can't remember ever having copying inerrupted in this way).
PFS3 has atomic commits. Basically the filesystem will stay valid regardless when the system is powered off / crashes. Obviously you will lose the data that was being written at the time.
SFS uses journal (https://secure.wikimedia.org/wikipedia/en/wiki/Journaling_file_system).
FFS does not provide either.
-
PFS3 has atomic commits. Basically the filesystem will stay valid regardless when the system is powered off / crashes. Obviously you will lose the data that was being written at the time.
SFS uses journal (https://secure.wikimedia.org/wikipedia/en/wiki/Journaling_file_system).
FFS does not provide either.
Personally, I'd put my money on journaling. As far as I know the SFS design follows the ideas laid out very eloquently in Dominic Giampaolo's book "Practical file system design with the Be file system" (http://www.letterp.com/~dbg/practical-file-system-design.pdf).
The book, which I bought when it was still in print, was very influential for me when I rewrote the FFS from scratch. I considered adding journaling support to the FFS, but decided against it. Even with journaling support, the FFS would have been weighed down by its comparatively poor data structure design.
Still, given a choice, I would feel much more comfortable with a file system for which working recovery and repair software exists, and make backups of the data I care most about.
FFS may be a poor choice in terms of performance, and all too easily end up in validation state, but if the chips are down you can at least scrape the data off the drive, even if you lost all information about your partition layout. Last time I looked, you were in a world of pain if PFS3 or SFS failed you under circumstances in which FFS would still allow you to sift through the embers.
-
FFS may be a poor choice in terms of performance, and all too easily end up in validation state, but if the chips are down you can at least scrape the data off the drive, even if you lost all information about your partition layout. Last time I looked, you were in a world of pain if PFS3 or SFS failed you under circumstances in which FFS would still allow you to sift through the embers.
PFS3 has a recovery and repair tool since ages. MorphOS has a SFS repair tool (SFSDoctor).
Even with FFS there are limited number of repair/recovery tools that support DirectSCSI/TD64/NSD or that don't freak out if you have little RAM and huge filesystem.
-
Nothing is funnier than the FFS validator itself crashing, which was something that happened every now and then on my OS3.5 or 3.9 systems. :)
-
PFS3 has a recovery and repair tool since ages. MorphOS has a SFS repair tool (SFSDoctor).
Even with FFS there are limited number of repair/recovery tools that support DirectSCSI/TD64/NSD or that don't freak out if you have little RAM and huge filesystem.
But doesn't this apply to all 68k file system recovery tools in general? While things are bound to be better in MorphOS land, on WinUAE or any "classic" hardware you're stuck with old, older and ancient recovery/repair tools which limit how large you can make your partitions, or select your disks.
As for PFS3, I have no idea how the on-disk data structures look like and how effective the recovery tools are on the 68k platform.
SFS may be tricky, though, as the file system was something of a work in progress until the author ceased development and handed over the source code. If I remember correctly, there was no assured compatibility between the different file system versions and platform variants. So you probably had to choose wisely when picking the file system and the recovery tool.
-
As for PFS3, I have no idea how the on-disk data structures look like and how effective the recovery tools are on the 68k platform.
The tools are for 68k (obviously they work with MorphOS as well). They've always worked for me when I've made a mess of things.
SFS may be tricky, though, as the file system was something of a work in progress until the author ceased development and handed over the source code. If I remember correctly, there was no assured compatibility between the different file system versions and platform variants. So you probably had to choose wisely when picking the file system and the recovery tool.
Yeah it indeed is unfortunate that certain parties took liberties and changed the filesystem without permission (the original agreement was for porting only). I've been told however that MorphOS SFSDoctor is able to recover OS4 SFS filesystems. Pegasos II users can be MorphOS CD as a recovery CD, others would need to plug the HDD to MorphOS capable system.