SFS Benchmark

After my last updates (checkout and test, please) SFS became stable enough to let it work on a real hardware, on native. As a reminder, I will firstly show the raw performance of my harddrive running through ata.device:

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Read from SCSI: 6805708 bytes/sec
Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Read from SCSI: 57461964 bytes/sec

Now, the SFS partition has been created with 1 sector per logical sector (kind of standard on Amiga) and with all debug turned off. The resulting performance is following:

Testing directory manipulation speed.
File Create: 17744 files/sec
File Open: 26498 files/sec
Directory Scan: 40269 files/sec
File Delete: 10258 files/sec

Seek/Read: 6424 seeks/sec

Please note that the slowness of file operations (create/open/dir scan/delete/seek) is due to enormous amount of context switches. I will probably improve it later, so expect it to be twice as fast soon. Now the real performance:

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 11043136 bytes/sec
Write to file: 13080896 bytes/sec
Read from file: 12458496 bytes/sec

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 25875456 bytes/sec
Write to file: 31401984 bytes/sec
Read from file: 16304640 bytes/sec

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 51707904 bytes/sec
Write to file: 62603264 bytes/sec
Read from file: 15536128 bytes/sec

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 53837824 bytes/sec
Write to file: 31686656 bytes/sec
Read from file: 77266944 bytes/sec

It should be noted, that even with 512-byte buffers the performance is pretty good (11MB/s in the worst case) thanks to a nice cache handling and read-ahead of the SFS. The numbers are of course a bit disturbed (noone will belive in 77MB/s transfers :)), but give some nice hint about the speed of the SFS. Hmm, isn’t SFS nice?

PS. I have tried to stress SFS partition a bit, copied many times, benchmarked and such 🙂 No errors have been reported by SFS. Therefore I consider it as a pre-release version (beta was yesterday :)))

Wanna try out the SFS?

Do you want to try my version of Smart File System out? Go here (or simply click on the title of this post) and enjoy.

PS. Have I already mentioned, that this version is free of checksum-bugs? Theoretically it should work as stable as the original SFS version 1.84. In practise it may behave better, since I’ve already fixed some issues which were present in the original code.


I have found and fixed a nasty bug in Smart File System. The filesystem was never setting the lock/handle type to ST_ROOT. Therefore, plenty of dos.library’s functions failed to work. That was the reason why the C:Dir and C:List commands failed to work on SFS partition, too.

I’ve fixed this issue now, and the filesystem seems to work properly now. Well, actually it still has some problems with checksums on admin blocks (I’ve copied my whole SYS: to the SFS partition and I saw five or sixchecksum errors), but I hope to solve it really soon.

Stay tuned 🙂

Smart Filesystem

Tonight, I have managed to compile the Smart Filesystem (SFS) for AROS! The whole internals are already there, but the filesystem cannot do very much yet. It detects a formatted (with AROS!) partition properly, allows to format a partition and to create directories on it. The rest doesn’t work properly yet.

The SFS will be able to work in both BigEndian and LittleEndian modes, allowing maximum performance on desired platform and, by the same time, the compatibility with other SFS variants. Additionally I will try to clean the code up (yes, it is messy right now) and fix some bugs present in the code.

At the end, the SFS sources for AROS (they are already in our SVN repository, check the contrib/SFS) will be synced with the SFS repository on the sourceforge.net. If the need arises, this version of SFS will be ported to the m68k AmigaOS.