AmigaOS 3.2 released!

[mfilos]

Originally Posted by orphan264

mfilos - congrats! I am intrigued by what you were working to achieve, but I haven't completely understood the discussion/suggestions you were trying. Would you be so kind as to post an example of your script that is now working so I can see how you managed to make it work?

Certainly mate.

First of all I made a Themes drawer inside SYS:Prefs/Presets and assigned it as Themes: early in Startup-Sequence.

Inside my Themes I have drawers for every theme I have with the following drawers:
- Backdrops (backdrops my theme is using - WB/Window)
- Prefs (.prefs file that I want my skin to hold like Font.prefs, WBPattern.prefs, GUI.prefs and OFC birdie.prefs-check attachment)
- VPrefs (VisualPrefs images including Birdie's Active/Inactive picture to use with)

This is what's inside my Themes drawer:


For example when I want to select a theme I put a record in ToolsDaemon doing 2 things:
1. SetEnv ENVARC:Theme <theme name>
2. Execute Themes:Apply-Theme (check attachment)

When the Apply-Theme runs, it gets the theme variable ($Theme) assigned before (on ToolsDaemon menu click) which is the same value as the theme drawer and HardLinks every prefs file inside the theme's drawer to ENVARC prefs files.
Once it's ready it requests a reboot in order for Birdie/VPrefs running the new theme applied.

The Startup-Sequence loads whatever is needed like:

...
C:AddDataTypes REFRESH QUIET
Run <>NIL: C:TitleShadow                ; --- Shadow in titles
Run >NIL: C:VisualPrefs                 ; --- Configure GUI look

C:IPrefs
C:FPPrefs                               ; --- Define, save & lock all WB colors

Execute Themes:Birdie-Startup           ; --- Birdie theme initializaion

C:ConClip
...

P.S. Don't forget to get the prefs you want for your theme from ENVARC: and ENVARC:Sys via copying them to your Theme's drawer/Prefs/ (and change the Apply-Theme accordingly to your liking)

It's not that hard once you get the idea
Check the scripts I attached and you can ask if you have any question.

[klx300r]

Originally Posted by Thomas Richter

That's actually the territory of DiskSafe, which will install a reset handler to ensure that the FFS (or any other file system) has written out its cache before the reset reaches the system.

Thanks for this very important reminder

[mfilos]

Hi.
I encountered an issue (which after a lot of headbanging I realized what the problem was) and I thought I would share in case you find anything about it.

So... in my Vampire V4-SA my fresh copied (from WinUAE) system gave me this error message on every COLD boot, after the last line on Startup-Sequence ( EndCLI >NIL: ).
(Error description comes from MCP's NoGuru patch that instead of the classic halt window, gives more information about the error and you can remove the halted process)



When I clicked the REMOVE button, then process was disabled and I had no problem at all. If I rebooted, then no error window appeared again (unless I powered off). On next power on, the error window appeared again!!!

Ofc, first thing I tried was removing all my patches from S-S, disabling WBStartup programs etc (in case there was an incompatibility of any sort) but the error window on first boot persisted.

The disk I was using was a 32GB CF, so I used another one I had around (4GB one) with same system partition (500MB) copying all data from my WinUAE main system.
Cold booting didn't give me an error! :O


I figured then that since it was the same setup with same data, something must be wrong with my partitions...

So... I re-initialized the 32GB CF from scratch from my Vampire and started adding partitions one by one (and cloning the data from my WinUAE environment)
- Adding the 1st partition (500MB) FFS (DirectSCSI, Long Filenames) --> NO error window after cold boot!
- Adding the 2nd partition (500MB) PFS3 (PDS\03) and BAM! --> Error window appeared after PFSFormating the volume and cold booting.
I then deleted the partition and re-added it but as FFS (DirectSCSI, Long Filename) this time. NO error window on cold boot!
Out of curiosity I replaced FFS with SFS (SFS\00) on the same partition and I also got no error window. When I added data to the SFS partition... same error window appeared and I can't boot (despite the priority=4 on my DH0) unless I disable the SFS boot (priority=0) partition.
- Added the rest of the partitions (always as FFS) and I never got an error window in any type of boot.

Both FFS and PFS3-AIO (50445303 PDS\03) were on the RBD.

Is there a problem putting different filesystems (FFS/PFS3/SFS) on different partitions of the same disk?
If there's no actual problem (that can't be reproduced) maybe it could have been a problem with Vampire so I can contact the team to troubleshoot.

EDIT: I was wrong that SFS worked without issue. It worked until I started filling data with it, then on next cold boot it gave the error window as well... :S

[Peter]

Can the 3.2.1 latest Rom/Kickstart files for an A1200 Winuae setup be purchased? I don't have an actual Amiga these days so would not need the physical chips... I cant see this option listed on any of the supplier websites.

[jbenam]

Originally Posted by Thomas Richter

That's actually the territory of DiskSafe, which will install a reset handler to ensure that the FFS (or any other file system) has written out its cache before the reset reaches the system.

IMHO a similar behaviour should be built-in in OS3.3. Since AmigaOS doesn’t have a real shutdown process it’s the logical thing to do system-wide to protect the user from any accidental filesystem corruption.

[boemann]

Originally Posted by Peter

Can the 3.2.1 latest Rom/Kickstart files for an A1200 Winuae setup be purchased? I don't have an actual Amiga these days so would not need the physical chips... I cant see this option listed on any of the supplier websites.

Sure - You buy the 3.2 which is a CD. no chips. To get the 3.2.1 and soon 3.2.2 you just register the serial number and download the updates for free. There are rom files included that you just use in your emulator. No need to buy the physical ROMs

[Peter]

Originally Posted by boemann

Sure - You buy the 3.2 which is a CD. no chips. To get the 3.2.1 and soon 3.2.2 you just register the serial number and download the updates for free. There are rom files included that you just use in your emulator. No need to buy the physical ROMs

Thank you..

[mfilos]

These last 2 days I'm getting Disk Not Validated issues on booting my FFS DH0 partition. I have a 2nd partition (SDH0) which I copy my progress each day so I usually ChangeBootPri SDH0: Boot, ChangeBootPri DH0: NoBoot makes my 2nd partition boot, then reformat my DH0: partition and copy back and forth and all good...

Funny part is that my DH0 partition works just fine when I boot from the other one and if I copy everything, reformat and recopy, nothing is lost.

I don't understand why this is happening though...
It always seems to stuck on my S-S when I delete ENVARC:Sys/ScreenMode.prefs (before I make a hardlink to it). If I pass this line, it stucks on delete SYS: Devs/Picasso96Settings (before I hard link it again).
Does my FFS doesn't like deletes? lol

I tried changing my Max Transfer from 0xFFFFFF to 0x1FE00 which seems to fixed the validation problem (no error window) but freeze still happens.

The CF I use is a 32GB Sandisk Extreme Pro which is 1 month old. Is it something with my setup, CF or possibly FFS?

Could that be related to the Ram-Handler bug (as both files that I delete are hardlinks) which is already fixed for 3.2.2?
(Edit just tried to overwrite a hardlinked file to the non validated partition and failed miserably, so it's definitelly something wrong with the hardlinked files that cause this weird freeze). It lets me rename it though :/ )

[npagonis73]

Just to add to your post above that i never managed to create a working workbench installation with anything other than pfs3. Tried the ffs that came with 3.1.4 and 3.2 and nothing. It always gets stuck somewhere on boot. As soon as I change FileSystem on my installation and use pfs3 then all works fine again.

[mfilos]

It's the first time I'm using FFS after MANY years (of using SFS and lately PFS3aio) seeing from the FAQ about the updates it got.
From other posts I saw that it's not recommended to use SFS (not that it's bad, but it's support is over for long time). Also I haven't actually seen anyone saying anything bad for FFS so I gave it a shot.

I didn't have problems all this time using it (both on my A600 with Vampire V2, and my Vampire V4SA). Problems started after using HardLinks which definitely cause issues.
If that's due to the ram-handler, we can live with that till 3.2.2 hits.
If it's something wrong with the FFS though, it's something that needs to be addressed or we need to be informed of using something different (PFS3, or SFS) until it gets troubleshooted.

I'm open to any suggestion and I can share whatever is needed in order to help devs tbh, but having to reformat every once and a while, definitely takes away much of the fun

[tomcat666]

I am not exactly sure why anyone would use anything but PFS3? It is the most robust solution, absolutely no problems with it, while with FFS people are constantly reporting issues. Just use PFS3 and you will never look back (or have to look at the disk validator popup), trust me.

[mfilos]

We know about PFS3's stability mate. I've been using it for years so nothing new here.
When I saw a new AmigaOS release though, I thought that trying an updated FFS would be nice as a test. We can always learn new tricks.
If stability is an issue, it's really easy to revert to the new old stable solutions, but we need to know that instead of saying that something is wrong without testing

[tomcat666]

Having a disk validator run for a day on a 64Gb disk because a program crashes during a write is very much wrong It was tolerable on the disks 30 years ago, no questions there, but today I would not really go even trying it.

[mfilos]

So, I changed all filesystems on my CF to PFS3 (PDS\3) and reformated/recopied everything and all work ok.
Haven't saw any error windows (post #1143) since yesterday nor disk validation issue so far, or HardLink delete problems.

[Olaf Barthel]

Originally Posted by mfilos

Does my FFS doesn't like deletes? lol

I tried changing my Max Transfer from 0xFFFFFF to 0x1FE00 which seems to fixed the validation problem (no error window) but freeze still happens.

The CF I use is a 32GB Sandisk Extreme Pro which is 1 month old. Is it something with my setup, CF or possibly FFS?

Which version of the scsi.device are you using, specifically? I expect it will be part of the AmigaOS 3.2 ROM, but you never know until you've checked.

Which mode of operations are you using PFS3 with? Direct SCSI mode?

Could that be related to the Ram-Handler bug (as both files that I delete are hardlinks) which is already fixed for 3.2.2?

ram-handler and the FFS, thankfully, share no common code but they used to share the same bugs. So I'd say this is mere coincidence.

[Olaf Barthel]

Originally Posted by mfilos

So, I changed all filesystems on my CF to PFS3 (PDS\3) and reformated/recopied everything and all work ok.
Haven't saw any error windows (post #1143) since yesterday nor disk validation issue so far, or HardLink delete problems.

Careful, please. You do have a backup of your data, don't you?

[Olaf Barthel]

Originally Posted by tomcat666

Having a disk validator run for a day on a 64Gb disk because a program crashes during a write is very much wrong It was tolerable on the disks 30 years ago, no questions there, but today I would not really go even trying it.

It's too late to fix that elegantly, or even safely. Adding write-ahead logging to the existing FFS is doable, but would require changes which are not necessarily backwards compatible (and also have to involve somebody who's more experienced in reading and writing 68k assembly code than myself).

While the FFS scales to scary storage device sizes on account of its use of 32 bit integers for the partition parameters and the file system data structures, it is unwise to go beyond a total partition size of 2 GBytes. It will appear to work just fine for larger partitions until it quietly begins to malfunction.

[fgh]

Originally Posted by Olaf Barthel

While the FFS scales to scary storage device sizes on account of its use of 32 bit integers for the partition parameters and the file system data structures, it is unwise to go beyond a total partition size of 2 GBytes. It will appear to work just fine for larger partitions until it quietly begins to malfunction.

So you are saying the recommended max partition size for the new (and old) FFS is 2GBytes?
How does it malfunction?

[Thomas Richter]

The partition size is not really an issue. The FFS only goes for the very last step, interface to the device, to &quot;byte offsets&quot;, and those are 64-bit clean if your device talks TD64, NSD64, or Direct SCSI. The limiting parameter is the block-count of the partition, and the size of individual files.

With 512 bytes per block, you can have 2^31*512 = 2^(31+9) = 2^(40-(10+10+10)) = 1024 GB partitions already without running into a limit in terms of block count. It is not *advisable* to use such small block sizes for such large media, but that is a different issue, namely of holding the bitmap for block allocation in memory. Every block requires one bit (approximately) for administration, so with 2^40 blocks, you need already 2^(31-3) = 8MB of memory for the bitmap.

It is getting better with larger blocks, also because solid state disks use internally larger block sizes, typically 4096 = 2^12 bytes.

The maximum file size is another issue, because the file pointer is a 32-bit integer such that you can only safely seek to a file position within 2GB as Seek() takes a signed integer as offset. But that is unrelated to the partition size.

Older versions of the FFS had limitations in terms of the bitmap and thus in terms of the maximal partition size, but that does not apply anymore.

[Olaf Barthel]

Originally Posted by fgh

So you are saying the recommended max partition size for the new (and old) FFS is 2GBytes?

If you expect dependable and predictable, sound behaviour (including a working validation process, if needed), you ought to stay within the parameters for which the FFS was designed. These parameters are signed 32 bit integers, which means that basic file system operations (read, write, seek) are sound only within 0..2,147,483,647 sizes and byte offsets.

Given the complexity of the implementation, it is hard to say if it "knows" its own limitations. For example, the hard limit with regard to what is possible in terms of disk space managed is the total number of blocks. This is a 32 bit integer, which means that the file system can manage only 2,147,483,648 blocks. Each block is represented by a single bit in the allocation bitmap and the FFS tends to keep the entire bitmap in memory (you'd need 268,435,456 bytes of RAM for that).

How does it malfunction?

File sizes > 2 GBytes are a problem because the number of bytes recorded as the file size will overflow. Accessing file positions beyond the 2 GByte limit is possible, but you would have to do so incrementally because the API for that purpose (seek) considers negative numbers as relative to the reference position (current position, start of file, end of file) and that does not always have to work out.

If you limit the maximum sizes of the files, you are less likely to create conditions under which the position references may become ambiguous, hence staying below the 2 GByte limit will eliminate that challenge. There is also the problem of application software dealing with file sizes that large, which can produce unpredictable behaviour. Imagine a file read access retrieving the wrong data because the read position is not where the program assumed it would be (same thing for write access, which is likely going to have more dire effects).

I am not qualified to fully understand how the FFS deals with the signed/unsigned 32 bit integer issues. From my own experience with the 'C' reimplementation of the FFS (for MorphOS and AmigaOS4), the ambiguity of the file positioning and how random access works, is an issue which can be resolved only at the application level.

You can address one half of this within the file system, e.g. validate file position and read/write parameters, but outside this domain you cannot tell which software is unsafe to use with file sizes exceeding 2 GBytes. AmigaOS4 and MorphOS alike at least have support for large file sizes, but these API functions have to be used deliberately, and legacy software might not even be aware of them.