Hard File Block Size >512 causes WinUAE to shut down

[Graham]

I am trying to create a hard file with block size 4096. It seems that when using larger than 4GB hard file the Amiga will boot slow because it is taking longer to validate the disk and the work around in the 3.1.4. doco says to make block sizes larger than 512 e.g. 4096 or more.

*Problem is when creating a hard file with block size=4096 and booting the Amiga up, WinUAE waits for a bit then just shuts down.

I can however make a hard file with block size=512, and then partition the hard file with HDToolBox and make partitions with block size=4096.

*Question is, does making the hard file with block size=512 and partitions with block size=4096 still take effect or does the hard file block size=512 counteract the partition block size=4096 setting?

*The Amiga does boot ok but not much increase in boot speed suggesting maybe still taking time to validate the hard file partition when booting.

How can I make a hard file with block size=4096 so that WinUAE does not quit and the Amiga boots ok? It would be interesting if this improves the validation process on boot up and reduces boot time.

I am using A1200 Quickstart settings with ROM version that supports >4GB hard disk, and modified this template in various ways; e.g. increased Chip RAM to max, increased Z2 Fast RAM to max, added RTG board and increased Z3 Fast RAM, and of course using Full drive/RDB mode with FFS support. scsi.device version is 45.7, but I have used uaehf.device and modified HDToolBox tool types to recognise this.

I am not using ClassicWB but going through my own process from scratch. This should provide more opportunities to customise the Workbench installation how I want it and not be stuck with unmaintained ‘all in one’ packs that may not be updated in years. I may use something like ClassicWB later but giving customisation a go with out it.

Any ideas would be greatly appreciated. I have been searching and racking by brains to no avail

Cheers.
Graham.

[mark_k]

Which version of WinUAE are you using? Can you post the log output when it exits/crashes?

Which emulated HD controller are you connecting the HDF to? If IDE, that probably explains the problem! The IDE specification only supports 512 bytes/sector. But WinUAE probably shouldn't exit in that case.

[Toni Wilen]

Assuming it is IDE, it probably is caused by some buffer overflow because IDE does not support other block sizes than 512. (and no one has tried previously)

There won't be any speed gains because filesystem reads/writres as many physical blocks as logical block size needs using single read/write command and no device driver is as stupid as doing reads/writes block by block.

[Graham]

WinUAE 4.3.0 (2019.12.19) 64-bit
HD Controller UAE (uaehf.device) + Full drive/RDB mode - HDToolBox tool types modified to uaehf.device

I changed the HD Controller to SCSI (Auto) + Full drive/RDB mode which does boot ok with the hdf block size=4096 but HDToolBox does not recognize the hdf - I tried with HDToolBox tool types = uaescsi.device also but HDToolBox still does not see the hard disk…?

Log output attached when it exits/crashes with HD Controller UAE (uaehf.device) + Full drive/RDB mode + block size=4096 - HDToolBox tool types modified to uaehf.device

[mark_k]

Maybe winuaelog.txt could provide more info? Also check Enable full logging in WinUAE Paths settings.

[Graham]

Ah thanks for the tip; winuaelog.txt attached.

[mark_k]

Ah I don't think that's much more help. You could perhaps try running WinUAE with -log -scsiemulog arguments but can you post the config file you're using too?

[Toni Wilen]

I haven't yet debugged this (CPU stuff to do first) but config file probably is needed.

[Graham]

Logs and config attached.

I executed with using following:
C:\Amiga\WinUAE\winuae64.exe -f .\Configurations\Amiga1200_3.1.4.uae -log -scsiemulog

[Toni Wilen]

Physical max reserved buffer size was 2048 bytes (to support mounting HDFs as fake CDs) but there was no range checks. Max will be increased to 8k and range check will be added (if larger, ignore the drive).

[mark_k]

8KB is the largest real-world-hardware sector size that I'm aware of. (DVD-RAM has physical sector size 32KB but I think all drives emulate 2KB size.)

[Graham]

So for understanding, this would allow for media (hdf) greater then 4GB, on a system that is slow, where it is generally advisable to use larger block sizes (i.e. not 512 bytes/block which is the default, but at least 4096 bytes per block, i.e. one block is 8 sectors).

Section 2.7 * in http://se.aminet.net/docs/help/AmigaOS_3.1.4-FAQ.txt

[mark_k]

For modern FFS versions (V39 and later I think) the filesystem block size doesn't have to match the drive sector size, it just has to be a multiple of it.

So you can, with a "normal" 512 bytes/sector hard drive, define an FFS partition with 4KB (or 8KB, 16KB, or 32KB) block size. There should be no performance difference whether the drive has 512- or 4096-byte sectors.

I guess the new FFS with OS 3.1.4 does some kind of forced validation every time the partition is mounted. Older FFS versions only validate if the bitmap was marked as invalid. (That would typically happen if you write some data then reboot too soon, before FFS could update the root block.)

You could try, for testing purposes, using a patched FFS 45.13 instead. Or maybe someone could figure out a patch to the latest FFS to remove the forced validation...

[Graham]

The problem was, that when selecting say 4096 Block size: in Properties of the Hardfile Settings to counteract slowness, WinUAE would instead just exit/crash after starting the Amiga, so not able to test any performance increase if any with media (hdf) greater then 4GB, but I get your point. I will see what happens with using patched FFS 45.13 instead...

[mark_k]

Kind of related to this thread, I've been experimenting with FFS and 32KB partition block size.

FastFileSystem v36 and later supports block sizes up to 32KB. FFS v39 (or v40?) and later support "SectorsPerBlock", which allows large-filesystem-block partitions to be more easily handled/defined by HD partitioning programs. (E.g. the partition doesn't have to begin on a drive sector which is aligned to a multiple of the filesystem block size.)

However with v36 FFS it's a bit tricky. The fake geometry in the RDSK sector (as written by HDToolBox) relates to the drive's sector size (typically 512 bytes). But a different geometry needs to be used in order to define a partition with larger filesystem blocks.

I created a test HDF to demonstrate this. In the RDSK sector the geometry is 1024 cylinders, 2 heads, 64 sectors/track. There is one FFS partition defined with this geometry in the PART sector:
LowCyl = 2
HighCyl = 1023
Surfaces = 1
BlocksPerTrack = 2
BlockSize= 32768

(I did that by defining a partition with HDToolBox then hex-editing PART sector data to change SizeBlock from $80 to $2000 etc.)

That seemed to work fine. I could install Workbench 2.1 and boot from it.

Is it possible to have WinUAE boot from the raw partition (i.e. not use full drive/RDB mode)? I extracted the partition from the full-drive HDF and tried to configure WinUAE to do that. In Hardfile Settings I set surfaces=1, sectors=2, reserved=2, block size=32768 and selected FFS 36.104 for FileSys. WinUAE shows the correct info: 1022/1/2, 2044/2044 blocks, 63.9MB/63.9MB

On booting WinUAE 4.3.0 reports:
hd: poscheck failed, offset=4000 not aligned to blocksize=32768! (4000 & 8000 = 4000)

Then on clicking OK WinUAE crashes/exits.

Archive with full-drive and extracted partition HDFs, two WinUAE configs:
hXXps://www.media!fire.com/file/g5iy78qebi9ldig/32KB_FFS_BS_test.7z/file