SFS2 buffer alignment issue

I've encountered an issue when I want to unpack an LHA archive from an SFS02 partition to anywhere.
While doing so I've noticed that SFS2 sometimes request data from the block device (SSD) to a non-32bit aligned memory buffer address. For example a cmd_read with lenght 18532 (=26x 512 bytes blocksize) to memory address 0x60C88FA5. This is a byte aligned address. It is at this point that I get an unpack checksum error. The archive itself is ok. I can copy it from the SFS2 partition to RAM and it unpacks just fine from there.
I have checked Media Toolbox but the Mask is set to 7FFFFFFC for this SFS2 partition. This should be "Any memory - 32bits aligned".

Does SFS2 ignore the Mask setting on purpose? Or is this a bug in SFS2?
Anyways, my block device requires at least 32bit aligned DMA accesses. So is there a way to force SFS2 accesses to be at least 32bit aligned?

I only see this issue with SFS2. NGFS for example seems to align the buffers to the blocksize. Unpacking from a ngfs partition on the same block device works just fine. This seems to rule out LHA/xadmaster itself.

I could work around it to detect the non-aligned transfer and move the read/write contents to a 32bit aligned intermediate buffer. But I like to avoid this because it will result in a performance penalty.

SFS version string: SmartFilesystem 1.293 (19-11-2015) AmigaOS4 PPC A-EON Technology Ltd

@geennaam
Quote:Yes, as well the other workarounds for old, broken device drivers (MaxTransfer, BufMemType, etc.) which had to be used on AmigaOS <= 3.9.

Quote:No, except for using an AmigaOS 3.x/m68k version instead of the AmigaOS 4.x/PPC one
Internal reads/writes (buffers, caches, incl. the diskcache.library ones, etc.) are block size, or at least 32 byte (CPU cache line), aligned, but for direct reads/writes to/from application data pointers SFS doesn't change anything and passes the address and size to the device driver.

Quote:AmigaOS 4.x device drivers have to do that, not only for unsupported alignment but unsupported (too large) transfer sizes or physically fragmented memory (when using DMA) as well.
Quote:Of course, but it would be even worse if the filesystems would do it instead of the device drivers, only the device drivers know their exact hardware limits.

@joerg

Ok, so the rules are: There are no rules in the Amiga jungle.

Mask or other properties are ignored and everybody has to plan for the worst.
I guess this is the result of the demise of commodore and lack of documentation in general. Nobody takes the lead in "how things shall be done" and therefore it's free for all.

Unfortunately this also means that it makes no sense to introduce new technologies to the amiga. Because any speed advantages that this new technology might bring is negated by the necessary gate keeping overhead on top of other speed limiting constructions of AmigaOS4.

If this sounds harsh then please note that it's nothing personal. Just me expressing my disappointement in general for wasting 2.5 months on a new device driver which was supposed to bring new storage technology to Amigaos4. Only to find out that the actual speed will be nowhere near its potential. Just marginally faster than SATA.

@geennaam
Quote:Wrong, it was decided by the AmigaOS 4.x development team more than 20 years ago that AmigaOS 4.x device drivers have to work with any alignment, any transfer sizes (as long as it's a multiple of the sector size) and any memory type and hacks like Mask/MaxTransfer/BufMemType/etc. are no longer supported.

One of the reasons was that the Mask/MaxTransfer/BufMemType/etc. workarounds for broken drivers used in AmigaOS <= 3.9 can only be used by filesystems on HDs using a RDB, but nothing else using device I/O (MediaToolBox, AmiDVD, etc.) can get such information to implement required workarounds for specific device drivers and even filesystems used on removable media (CD/DVD, USB, etc.) can't work that way.
Another reason was that users usually don't know which bugs/limits device drivers have and which workarounds (Mask, MaxTransfer, etc.) may have to be added in all partitions of a HD in the RDB in HDToolBox/MediaToolBox.

Quote:There is no speed difference between a filesystem using an intermediate buffer or the device driver doing it for transfers not supported by the hardware. In your example it's a memory pointer in LhA which isn't aligned, not something in the filesystem.

@joerg

Let's assume that you're telling the truth that is was the "official" direction to solve alignment issues at the destination (drivers) instead of the source (OS4 applications). Then where can I find this information as mortal being? And what more undocumented skeletons are there waiting for me in the closet? Or are non-os4 development team members not entitled to this information?

And why is there still the option to set those masks in media toolbox of OS4.1FE when it was "officially" decided to ignore them for >os3.9 anyways? Or did the OS4 team envision that the future for OS4 was to use old 68k mass storage drivers?

And why is Sfs2 exposing this issue where ngfs isn't? Or is Sfs2 this fast because it simply passes on the problems where eg. ngfs doesn't?

Anyways, I cannot take responsibility for a device driver when I do not know which design rules apply.

@geennaam
Quote:Putting the alignment requirements into the applications instead of the device drivers wasn't possible when the AmigaOS 4.x project was started, 99,9% of the applications were still old AmigaOS 3.x/m68k software.

As for the documentation: I don't know where it is, I only did some AmigaOS 4.x development but none of the documentation parts, and I'm no longer part of the AmigaOS 4.x development team since a very long time.

Quote:It's required for classic Amigas (A1200/A3000[T]/A4000[T]) where AmigaOS 4.x is booted by AmigaOS 3.x using AmigaOS 3.x/m68k device drivers and 3.x/m68k filesystems.

Quote:No idea, I don't know how NGFS works internally.

But I did have access to the FFS2 sources and IIRC it should be the same as with SFS2, at least if you use Mask 0xFFFFFFFF in the RDB.
(FFS2 was using the same sources for the AmigaOS 3.x/m68k, 4.x/PPC and MorphOS/PPC versions, still supporting Mask/MaxTransfer/etc. in all versions. For SFS I used independent sources for both versions instead and only the 3.x/m68k sources still included the Mask/MaxTransfer/etc. support.)