Hyperion announces OS 3.1 update

[olsen]

Olaf is currently working on a new DiskDoctor to address this issue.

Um, well, this is still a work in progress and based upon a rewrite from scratch (there is no sense in rewriting or porting the original DiskDoctor). The goal is to make a command line tool which does three things: a) detect and report file system damage, b) recover data from a file system and c) repair any damage found.

The detection operation is a prerequisite to recovery and repair, and it will never modify the contents of the file system. You can save the information which the detection process gathered to a file and then use that file as the basis for recovery or repair later, or you can of course rerun the detection before recovery or repair are performed.

The recovery operation will likely work similar to how DiskSalv would do the job, with the difference that you would have a choice to copy only those files which are sound (like a "copy #? all clone" command), only those files which are not known to be sound (deleted, corrupted, etc.), or to perform a "deep salvage" operation which would copy everything that is even remotely recoverable, including data file fragments.

The repair operation would excise any damage found, returning the file system to operational state again. This is what the original DiskDoctor was intended to deliver, except that it rarely accomplished even that, and could be depended upon to leave the file system in a much more damaged state than it was before. You would use the repair operation only if you had previously recovered all the salvageable data.

The new DiskDoctor handles large volumes, on storage media larger than 4 Gigabytes. It supports all Amiga ROM file system flavours including dircache and long name mode, with block sizes up to 65536 bytes. Because large volumes need to be supported, covering hundred thousands of blocks, the new DiskDoctor is specially optimized to use as little memory as possible for its work. You may still need 10 Megabytes of RAM for very large drives, mind you.

This is a rather large project, I'm afraid and I cannot currently quote a release date.

[kolla]

I'm not yet at the prefs. Currently, the 3.9 Prefs work ok with it, and there aren't any new features beyond 3.9, except bug fixes.

Good. I ask for prefs since I have been using tweaked 3.9 on 68000 since forever, and the only really "big" problem are the prefs of OS3.9 that all depend on resource.library and Reaction, which are 68020+. And among them, only the Workbench prefs is lacking in 3.1.

I take it for granted that Reaction (and resource.library) are among the code that is ouch of reach?  All prefs programs rewritten with gtlayout.library would have been superb, and so ... fitting

[mindprober]

I have a ClassticWB_LITE OS 3.1 system installed on an A1200. PFS3 is installed as well. With this update, I saw that the native HDToolbox will be fixed to recognize large drives/partitions. I was wondering if the Workbench drive windows will be patched also to report the correct space used/remaining. This is currently not accurate.

Fortunately, I can use Dir Opus to get more accurate values but it would be nice to see the correct info in Workbench windows.

[ExiE_]

No, not at this time. The code is still the same assembler based FFS code it used to be before

Isn't Olaf the author of FFS2 written in C? Wouldn't be better base fixed ffs on these sources?

[guest11527]

I was wondering if the Workbench drive windows will be patched also to report the correct space used/remaining. This is currently not accurate.

This has been fixed already.

[guest11527]

Isn't Olaf the author of FFS2 written in C? Wouldn't be better base fixed ffs on these sources?

Maybe, in the long run. At this time, I still prefer the old sources. 68K is not exactly a fast microprocessor, and the FFS is a sort-of critical system component. It doesn't make much of a difference for PPC, and patching up the assembly code on 68K was not *that* much a problem.

[Oldsmobile_Mike]

Yes. Actually, we have currently three. DOS/6 has long file names, but OFS block layout. DOS/7 has long file names and FFS block layout. DOS/6 and DOS/7 are exactly as in AmgiaOs 4, but unfortunately not backwards comaptible to DOS/0 and DOS/1. Olaf is currently working on a new DiskDoctor to address this issue.

Then we have another stranger, and this is DOS/8 which will probably go. The fun part about it is that DOS/8 was "sort of present" already in the Os 3.9 version, but there not fully functional. It has 54 character long file names (so more than the usual 30), but is backwards compatible in the sense that the block layout is just like the one in DOS/1, except that unused fields are populated with the extra characters, so old tools will at worst damage the file name, but nothing else.

Probably we'll keep DOS/8 inofficial, as it used to be.

It will be interesting to compare these with PFS/SFS.  Any predictions which will be "better"?

[mindprober]

Sorry-- when you say "already", you mean it is included in the latest update or I should already have it with my current install?

Thanks.

This has been fixed already.

[olsen]

Isn't Olaf the author of FFS2 written in C? Wouldn't be better base fixed ffs on these sources?

Tough one. The FFS reimplementation which is used both by AmigaOS4 and MorphOS was designed and developed on AmigaOS 3.1. It has worked on 68k since, well, the day it actually started working properly

The FFS reimplementation would be a better foundation for future file system development work than the assembly language version. One of the drawbacks, compared to the assembly language version, is that the FFS reimplementation needs much more ROM space. Because it tries to do better in avoiding data corruption, the FFS reimplementation deliberately flushes modified blocks to disk, slowing write operations.

In the mid/long term perspective, I see the FFS reimplementation supporting journaling using write-ahead logging, which would solve many performance and reliability issues. I have a cunning plan how to make this work which could be compatible even with AmigaOS 2.x (which would not support the journaling, though).

[olsen]

It will be interesting to compare these with PFS/SFS.  Any predictions which will be "better"?

Always bet against FFS. Both SFS and PFS, in spite of limitations and bugs which may still be present, can't help but kick the FFS to the curb without even trying.

[guest11527]

Always bet against FFS. Both SFS and PFS, in spite of limitations and bugs which may still be present, can't help but kick the FFS to the curb without even trying.

Oh well, it really depends on what you are doing. As far as raw data transfer is concerned, neither file system can do any magic. It just has to take the user blocks, and direct the device to write them out. So far, so simple.

It gets more complicated for any higher file system operations. FFS is actually quite good at *locating files*, i.e. if you give it a name, to find the name. It is quite bad at *listing* files, as in directories. It is also quite bad at managing the space on disk - the algorithm for that is quite naive: Take the nearest block you get can.

So, there are certainly some options for improving the FFS - as a better allocation strategy - and some limitations I have no idea how to address at all.

[guest11527]

Sorry-- when you say "already", you mean it is included in the latest update or I should already have it with my current install?

No, I mean "I fixed this for the latest version I have". It is not fixed in your version. Beware! There is a third-party plugin "AsyncWB"(sp?) by Stephan Rupprecht which also has issues with large volumes. We don't have sources, so cannot fix it.

[mark_k]

Yes. Actually, we have currently three. DOS/6 has long file names, but OFS block layout. DOS/7 has long file names and FFS block layout. DOS/6 and DOS/7 are exactly as in AmgiaOs 4, but unfortunately not backwards comaptible to DOS/0 and DOS/1. Olaf is currently working on a new DiskDoctor to address this issue.

Then we have another stranger, and this is DOS/8 which will probably go. The fun part about it is that DOS/8 was "sort of present" already in the Os 3.9 version, but there not fully functional. It has 54 character long file names (so more than the usual 30), but is backwards compatible in the sense that the block layout is just like the one in DOS/1, except that unused fields are populated with the extra characters, so old tools will at worst damage the file name, but nothing else.

If you're adventurous, you can test out Toni's patched FFS 45.13 which fixes some bugs and enables DOS\8 long filenames! See this post on EAB.

[mindprober]

Thanks for clarifying.

No, I mean "I fixed this for the latest version I have". It is not fixed in your version. Beware! There is a third-party plugin "AsyncWB"(sp?) by Stephan Rupprecht which also has issues with large volumes. We don't have sources, so cannot fix it.

[olsen]

If you're adventurous, you can test out Toni's patched FFS 45.13 which fixes some bugs and enables DOS\8 long filenames! See this post on EAB.

When it comes to the FFS, one man's adventure is another man's daredevil stunt with tragically comic consequences.

Heed the warning: make backups of the data and check that you can restore them when needed, and only then maybe give this a spin.

[guest11527]

When it comes to the FFS, one man's adventure is another man's daredevil stunt with tragically comic consequences.

Yup. Unless Toni invested quite a bit of work, this will not do. About the only thing that was present of DOS/8 in the 3.9 release is ExAll() and friends, and the computation of the maximum file size. Everything else on file names in DOS/8 was there borken... Open, Rename, Lock, .... you name it. I cleaned this up for V46, so it now works quite fine on my HD since probably a year or so.

One way or another: DOS/8 is most likely not going to become official. Not because it is too experimental - rather because we have another alternative that is more flexible.