What are the correct settings (Blocksize, Buffers, Maxtransfer, and Mask) for a FastFileSystem 2 (DOS\07) partition on a SATA disk?
At the moment I’m using the following settings:
I have also a PATA SSD disk (CompactFlash memory card connected to AmigaOne’s IDE port) which has one SmartFileSystem partition (SFS\00):
- You must login to post comments
There’s nothing much wrong with the settings you have really. The AmigaOne and OS4 device drivers and filesystems don’t have the same limitations as their OS3 counterparts, so max transfer and mask don’t have the same importance. The values you have look like the defaults from MediaToolbox and should be fine.
For a background on the parameters:
- Block Size: This is the size of a single block of data on any storage device, and is the smallest unit that can be read or written, so even a file 25 bytes in size will occupy a full block. Changing this setting will destroy any data on the partition.
- Max Transfer: This is the largest chunk of data that can be transferred to or from the hard drive in a single operation. As said, the A1 and OS4 can handle any value here, so anything will do once it’s not so small it slows things down. The cache size of your drive might be a reasonable minimum, or the default of 7FFFFFFF is fine, which is 2GB. You won’t have this much RAM free anyway so you’ll never run into this limit.
- Mask: This setting is used to tell the device drive what portion of memory it can access for doing data transfers to and from the drive. Again, it doesn’t have much meaning for the A1 and OS4 because they don’t have the limitations of 24-bit motherboard access or drivers that only work with chip RAM for example, so setting this to FFFFFFFF will allow any available RAM to be used. This setting can also be used for controlling the alignment of memory allocated for transfers, which can help with efficiency. Values ending with F are non-aligned, with E will be aligned on 16-bit boundaries, and with C on 32-bit boundaries.
- Buffers: This is the number of blocks held in RAM as a cache. Bear in mind that it is blocks, not bytes, so the actual RAM taken up by buffers is (number of buffers x block size). So, for your hard drive example, you have 600 buffers allocated, which is 600 x 1024 bytes, basically 600KB, but for your CF card it’s 600 x 512 bytes, or 300KB.
Now, with all that in mind:
- FastFileSystem can use any power-of-two block size from 512 to 32,768 bytes, which allows the user to balance space efficiency for small files against speed. Some speed can be gained by increasing the block size. This will increase the amount of space used by files as they will all be rounded up to the next block multiple, so it’s a balancing act between space efficiency and speed. If you’re not too worried about space, go for a larger block size. Other filesystems generally only use a 512 byte block size so only do this with FFS/FFS2.
- While we’re talking about FFS, consider replacing it with SFS since is is a lot faster than FFS in everyday use, while still keeping the 512 byte block size.
- A mask of 7FFFFFFF limits the memory useable for transfers to the first 2GB of address space which probably isn’t a problem unless your RAM is mapped to a very high address, but it’s no harm to use FFFFFFFF here. Changing the last digit to C (so FFFFFFFC) will ensure that the memory used is 32-bit aligned, which means transfers could be more efficient. Whether you see a real-world benefit I’m not so sure since I haven’t tested it. Your mask of FFFFFFFE is 16-bit aligned with is better than non-aligned but potentially not as efficient as 32-bit aligned.
- You probably don’t need more buffers, but since you probably have a good bit of RAM spare on your A1 you could increase that value to 1,000 or more and see if it improves performance.
Finally, just a general note that this only applies to AmigaOnes running OS4 – classics will need different settings as the OS is still limited by their old hardware interfaces.
- Thanks for the thorough explanation! The reason for me asking is that I sometimes get read errors on the FFS2 volumes. The disk is brand new and its S.M.A.R.T. system doesn’t report any errors and the files are alright when accessed later with other applications.
- Hmmm… It shouldn’t be anything to do with those settings. It could be some issue with the DMA settings though, or an issue with your RAM. Run a memory tester to make sure your RAM is ok, and set the DMA mode of the drive to a lower mode to see if that helps. Opening the files in applications could be reading in smaller chunks or to different areas of RAM. Also, SATA cables can be troublesome so it might be worth swapping it for a known good one. As an aside, for all its faults and drawbacks, FFS does have some pretty good data integrity security built in, with checksums calculated for every block read for example (a hangover from its use for floppy disks). This means it can potentially pick up a minor fault that other filesystems ignore, thus preventing silent corruption of files and detecting bit rot.
- Running the memory tester was the first thing I did. Since there were no errors I though maybe there is something wrong with the partition settings. I experimented with the transfer mode settings in the UBoot preferences and it looks like the read errors are now gone. Apparently transfer mode “Best PIO” was the one causing the problem. Setting the unit type to “Harddisk”, transfer mode to “UDMA 6”, and ticking the “Use IRQ” seems to fix the problem. (I’m using a SIL3512 Serial ATA controller card with my SATA drive.)
- You must login to post comments
Please login first to submit.