Problem updating the file system in OS3.1.4.1

[Kitch]

I've just done a fresh install of OS3.1.4 on an A1200 fitted with an ACA1233, 3.1.4 ROM's and IDE to SD card adaptor.
I used a new 16GB SanDisk Ultra MicroSD card and I had the OS3.1.4 adf's loaded onto a Gotek drive.
After setting up four partitions 800MB, 2GB, 2GB & 800MB, changing the MASKs to 0x1FE00, quick formatting and then installing OS 3.1.4 everything seemed fine.
I check the file system version with shell and I got 46.13.

I installed the OS3.1.4.1 update and followed the instructions for updating the file system to 46.20.
I rebooted and everything seemed okay but when I checked the file system version again it still showed 46.13?
I repeated the procedure again but no change.

After setting everything up in a real Amiga I then put the same MicroSD card in a PC and used it as a HD via WinUAE, it shows the file system version as 46.20 when I check via the shell.
I put the MicroSD card back into the A1200 and it's showing me version 46.13 again.

I've had a couple of goes at completely reinstalling from scratch but I get the same result.
Any ideas what might make this happen or what I could try to fix it?

I updated the MMULibs after updating to OS3.1.4.1, but I didn't think that would have made a difference. WinUAE showed version 46.20 before I updated the MMULibs.

[thomas]

How do you check the version of FFS?

How many harddrives do you have in the Amiga? Do all of them have a copy of FFS on them?

What's the DosType (identifier) of FFS on the Add/Update screen? What's the DosType of your partition?

MASK should not be touched! Set this to 0xFFFFFFFF and leave it alone.
MaxTransfer can be changed to 0x1fe00 but does not need to with 3.1.4.

Setting Mask to something which has only a few bits set is counterproductive. It leads to higher memory usage and slower transfers. Mask should really only be adjusted if you have a DMA disk controller which has certain memory requirements. In this case the manual of the controller will tell you the correct value for Mask. In all other cases it should be set to all bits on.

[Kitch]

Hi Thomas,

Thanks for the reply.

In a shell window I type "version SDH0:" to see what version I have.

I have just one IDE to SD card adaptor connected to the IDE header on the A1200.

The identifier is shown as 0x444F5303 on the "File system Maintenance" (add/update screen) and it shows version: 46 and revision: 20.
The identifier value shown on the "File System Characteristics" screen looks like 0x44F5307, it's a bit hard to read because it's greyed out.

File system is standard file system, with the boxes ticked for fast file system and long names. The first partition named SDH0.

Sorry, my mistake. I hadn't changed the Mask, I had changed the max transfer to 0x1fe00.

As I mentioned hadn't changed the Mask but it shows 0x7FFFFFFE, not the 0xFFFFFFF that you've posted?

Some people still recommend changing the max transfer to 0x1fe00 if you have a CF or SD card with OS3.1.4 but that's no longer required with the updated file system?

[thomas]

Originally Posted by Kitch

The identifier is shown as 0x444F5303 on the "File system Maintenance" (add/update screen)

You should delete and recreate the entry with the same identifier as the partition. scsi.device only updates the file system if it finds a matching partition.

0x444f5303 a.k.a. DOS\3 is "FFS international"
0x444f5307 a.k.a. DOS\7 is "FFS long file names"

Originally Posted by Kitch

I then put the same MicroSD card in a PC and used it as a HD via WinUAE, it shows the file system version as 46.20 when I check via the shell.

Then you probably did not attach the SD card to the virtual IDE bus but used the default UAE controller. uaehf.device behaves differently and updates the file system even if it does not find a matching partition.

Originally Posted by Kitch

Some people still recommend changing the max transfer to 0x1fe00 if you have a CF or SD card with OS3.1.4 but that's no longer required with the updated file system?

It was never required because of the file system, it's because of a bug in the IDE driver. It's not even a bug, the driver just follows old IDE specs which do no longer apply to modern devices like flash memory cards.

3.1.4 fixed the bug in scsi.device, so limiting MaxTransfer is not needed any more if you keep the flash card in the Amiga with 3.1.4 ROM. If you move the card between different computers with different ROM versions it's better to set MaxTransfer to 0x1fe00. And it does not hurt anyway, so it's good to always set it to that value.

[Kitch]

Hi Thomas,

Changing the identifier to 0x444f5307 "FFS long file names" worked great and solved the problem.

I thought I had set it to use the virtual ID bus in WinUAE, I'll look into that.

Great explanation about MaxTransfer, that helps clear things up better for me.

Thanks for the help.

Can I ask what file system block size setting would you recommend for a 16GB SD card?
The default setting was 512 but I've seen people recommending changing it up to 4096?

[thomas]

There are several aspects to consider regarding block size:

from the file system point of view, I think that FFS becomes slightly faster if it can work with larger blocks. Also the partition size limit depends on blocks size, so with larger blocks you can make larger partitions. However AFAIK even with 512 byte blocks the partition size limit is much larger than 16 GB, so this is out of interest for you.

On the downside with larger blocks small files waste more space (which might not be an issue with a drive as large as 16 GB). And the amount of memory required for buffers multiplies by block size, so with eight times lager blocks you need eight times more memory for buffers.

There is also the hardware aspect. As CF cards are flash memory like SSDs, they might benefit from certain alignments. Using a block size which matches the physical cell size reduces the number of writes to each cell, but only if the position of blocks is aligned with physical cells, too. I usually recommend to change the geometry in HDToolbox so that one cylinder matches one megabyte (2048 sectors). Then all partitions are automatically aligned at megabyte borders and with 4096 byte blocks your system is perfectly aligned to SSD requirements.

[Kitch]

Hi Thomas,

I've been searching trying to figure out how to change the geometry in HDtoolbox so that one cylinder matches one megabyte but without much luck.

I also can't figure out why my size shown in drive definition in HDToolbox doesn't seem to match the value I calculate, I'm assuming I'm doing something wrong?

My 16GB SanDisk microSD card shows up in HDToolbox as:

Cylinders: 30869
Heads: 16
Blocks per Track: 63
Blocks per Cylinder: 1008
Size: 15193M (15 Gig)

When I calculate - Cylinders x Heads x Blocks per track I get:
30869 x 16 x 63 = 31115952
I then go 31115952 x 512 = 15,931,367,424.

Shouldn't the 15931M I calculate match the 15193M size shown in HDToolbox?

[thomas]

Originally Posted by Kitch

Shouldn't the 15931M I calculate match the 15193M size shown in HDToolbox?

No, it's the usual binary versus decimal.

In HDToolbox
1 KB = 1024 Bytes,
1 MB = 1,048,576 Bytes
1 GB = 1,073,741,824 Bytes

So your 15.9 billion bytes become ca. 14.8 GB in HDToolbox.

I've been searching trying to figure out how to change the geometry in HDtoolbox so that one cylinder matches one megabyte but without much luck.

Use Heads = 16, Blocks per Track = 128, Blocks per Cylinder = 2048.

Now divide the previously calculated total number of sectors (31115952) by 2048 to get the new number of cylinders: 15193.
And because now one cylinder equals one MB, you can easily say that the disk will have 15193 MB or 15193 / 1024 = 14.8 GB.

[Kitch]

Thanks for explaining that Thomas.

I can now see how the maths works out for a 2048 blocks per cylinder value.
Does that mean with those values set in the drive definition I would now need to select 2048 as the "File system block size" in HDToolbox?

If I wanted to use 4096 as the "File system block size" would I need to change the 2048 blocks per cylinder in the drive definition?

I read in another post where you mentioned the heads and the blocks per track values don't matter e.g. 1 x 4096 or 64 x 64 or 32 x128 or 16 x 256, as long as they end up at 4096.
If I was to take my current cylinder value of 30869 and multiply it by a head value of 16 and than multiply that by a blocks per track value of 256 I get 126439424.
If I divide that by 4096 I get 30869, which doesn't seem to work?

If I change my values in HDToolbox to the following-

Cylinders: 7597
Heads: 16
Blocks per track: 256
Blocks per Cylinder: 4096
Size: 15192M (15 Gig)

Which looks okay in HDToolbox but when I calculate - Cylinders x Heads x Blocks per track I get:
7597 x 16 x 256 = 31,117,312.
If I then go 31,117,312 / 4096 = 7597MB, half the size.

I tried changing the cylinder value to 15193 which worked in the calculation but HDToolbox now showed the drive as 30GB.

Apart from my lack of understanding, what have I missed here to be able to use 4096 as my block size?

[thomas]

No, you are comparing completely unrelated things.

The drive itself still communicates with the OS in units of "sectors" which are 512 bytes each. So the drive reports itself as 31115952 sectors of 512 bytes each.

These are the values used to communicate between the OS and the drive. But we know that internally the drive can only write complete 4k pages at once and erase only blocks of 64k or more at once. So we now tweak the geometry of the drive and the file system parameters to best fit the internal workings of the drive.

First thing is the geometry. AmigaDOS uses the unit of "cylinders" to define partition borders. A cylinder has no meaning to the flash memory drive, it's just a unit which is defined as a number of sectors. So to get a "cylinder" of 1MB we need to define a cylinder as 2048 sectors of 512 bytes each. We cannot change the 512, it's given by the drive. But we now made AmigaDOS align partitions at megabyte borders, i.e. each partition starts at a multiple of 2048 sectors.

Now to the file system. The file system uses the area between the start cylinder and the end cylinder of the partition to store files. It still needs to address the drive by the unit of sectors. But it can combine multiple sectors into a block which it uses as its own smallest unit.

If you define a file system block to be 8 drive sectors, then each block is 4096 bytes which matches the page size of the flash memory.

The size of the HDD and of a partition is still calculated by the number of sectors which are 512 bytes because this is defined by the drive. If you define a file system block as one drive sector, then the partition has as many blocks as it has sectors. By defining larger blocks for the file system you reduce the number of blocks on the partition, keeping the same size in bytes and sectors.

[Kitch]

Hi again Thomas, thanks for your patience with this.

So I spent the morning getting my head around drive geometry and it is making more sense now.
As far as geometry goes, I now understand better how cylinders x blocks per cylinder = the total sectors and how to get a cylinder to equal 1MB.

After setting the geometry do you then define a file system block to be 8 drive sectors by selecting 4096 as the "File system block size" in HDToolbox?

When defining new partitions, how do you now get the partition size to match multiples of 4096, does HDToolbox do those calculations automatically as you move the slider around to size the partition?
Or do those values now need to be manually calculated and entered into the "Start Cyl" and "End Cyl" boxes?

[thomas]

Originally Posted by Kitch

After setting the geometry do you then define a file system block to be 8 drive sectors by selecting 4096 as the "File system block size" in HDToolbox?

Yes, exactly. AmigaDOS defines the file system block site as "sectors per block". HDToolbox gives you the comfort to let you choose from the resulting block sizes.

Originally Posted by Kitch

how do you now get the partition size to match multiples of 4096

You might have recognised that all numbers we talk about are powers of 2. As such many of them are divisible by each other giving whole numbers.

4 KB = 8 sectors
1 MB = 2048 sectors

2048 is divisible by 8.

So because our partitions all begin and end at megabyte boundaries and a megabyte is divisible by 4096, the size of each partition automatically is divisible by 4096, too.

By setting a cylinder to match one megabyte everything works out automatically.

Even if you'd choose another block size, because 1 MB is a power of 2 and all block sizes you can choose are powers of 2, too, every partition size results in a whole number of blocks. Automagically

[Kitch]

Great, thanks for all the help Thomas.