Hyperion announces OS 3.1 update

[kolla]

now that workbench is on disk

Which workbench.library will 3.1.4 come with?

[Oldsmobile_Mike]

On an unrelated thought, where's that troll who used to always say you should never upgrade your Amiga to 3.1? Haven't heard from him in a while. Wonder how he feels about all this? :laughing:

[guest11527]

Which workbench.library will 3.1.4 come with?

V45, but a later release that goes beyond what was shipped with 3.9. I don't have the release here, probably something like 45.178 or so, but this is still going to increase as we find bugs.

In particular, it includes a couple of fixes for big partitions, and it copies softlinks and hardlinks correctly (unlike the 3.9 version which just left them out). Hardlinks will be copied within the same partition, and decay to softlinks across partitions (or this is the algorithm right now).

Oh yes, this is a ROM-able version again. I wrote about the whole story a while ago. It was costing me some nerves to get this working.

[LoadWB]

You must have read my mind.  I was mulling about with the 1MB KS ROM question (I have a ROMY for my 4000, and I understand the 1200 supports 1MB KS natively,) so being able to build my own ROM *could* be useful, or maybe the option to obtain official 1MB KS.

[Louis Dias]

ThoR & Olaf,
https://www.patreon.com/

Let the true Amigans support you directly.

[wmaciv]

Will the A4000T version have room for the SCSI + IDE device drivers?

[AmigaHope]

It would be cool if someone could put together a sort of "Boing Bag 5" that pulled forward improvements from 3.1.4 into 3.9 as well as could be applied. Some stuff (like HDToolbox as mentioned) might have to be downgraded to the "ugly" version, but as much of 3.9 as possible could be salvaged. 3.9 was a much nicer environment than 3.1 so it would be a shame to waste what could be salvageable from it.

btw does "Long-filename" FFS introduce a new identifier/dostype to reflect the changes? If it implements long filenames using the old dostype it would cause holy hell with tools that don't understand the changes but doesn't expect them to be there by recognizing the old FFS dostype.

Or does it implement it with some semi-compatible overlay like how Joliet/VFAT implements long filenames in Windows? (ISO-9660/FAT 8.3 MS/DOS-compatible filenames with extra metadata to contain the long names).

[kolla]

V45, but a later release that goes beyond what was shipped with 3.9.

Great! And a new prefs program to go along with it?
This OS3.1.4 (or whatever it will be called) sounds like exactly what I want

[kreciu]

On an unrelated thought, where's that troll who used to always say you should never upgrade your Amiga to 3.1? Haven't heard from him in a while. Wonder how he feels about all this? :laughing:

Don't tempt me, I'm thinking to become troll... Just for the sake of argument ;-).

...Few months ago I got fresh, new AmigaOS3.1 floppies and NOW I hear about update! Can we finally stop this updates I can't keep up. Now I will have outdated system.

[guest11527]

Will the A4000T version have room for the SCSI + IDE device drivers?

Yes, of course. It will not have room for the workbench and icon, but that is old news.

[guest11527]

btw does "Long-filename" FFS introduce a new identifier/dostype to reflect the changes?

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.

DirectSCSI works in a different way. This is not a DosType, but we recycled some flags elsewhere.

[guest11527]

Great! And a new prefs program to go along with it?

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. Did I say that this is a bugfix release?

[NorthWay]

(New filesystems)

Yes. Actually, we have currently three.

Have you pondered anything about how the Amiga filesystems perform with non-seektime storage like SSD/flash? Has some of the old tech choices become better or worse? Any minor tunings that can align better to this?

[olsen]

(New filesystems)

Have you pondered anything about how the Amiga filesystems perform with non-seektime storage like SSD/flash? Has some of the old tech choices become better or worse?

As far as I can tell the file system design choices made back in the late 1970'ies have not aged well. The file system does not have an effective strategy to organize the layout of directories, and the data structures associated with files so as to minimize access times. This is a major drawback which SSDs alleviate.

Even with these limitations out of the way, the design is still not sufficiently scalable and is still vulnerable to damage and corruption caused by the lack of journaling.

The file system design was adequate for the technology of the time it was created for, which would have been hard disk drives no larger than 20 Megabytes. It still strikes me as odd that this file system was used for floppy disks which were significantly slower than those hard disks and were a big source of trouble on account of the file system using a write cache.

Any minor tunings that can align better to this?

It definitely helps to use larger block sizes (2048 bytes or more), if the increased size does not negatively impact overall data throughput (changes are that throughput will be higher, though). The larger block sizes have beneficial effects on how file and directory data structures may be used. The tables which these data structure contain are larger, which reduces seek times, etc. Mind you, larger block sizes help with mechanical electromagnetic storage devices, too

That aside, the file system design provides little to no leverage to improve its performance by minor tuning exercises. It is, as I mentioned, a design which has not aged well.

[guest11527]

Have you pondered anything about how the Amiga filesystems perform with non-seektime storage like SSD/flash?

No, not at this time. The code is still the same assembler based FFS code it used to be before, with the same block allocation strategy as before, plus the three new layouts, plus TD64 support, plus directSCSI support, minus the bugs we (or others) found.

Thus, one may wonder in how far one can improve the old design. For mechanical disks, an improved block allocator would certainly help. For SSDs or CF, you can already use larger block sizes today. But before we introduce more bugs by changing algorithms, please let us remove the old bugs first. There is still plenty of work ahead, and experimenting too much with this old code has a certain danger.

[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.