FFS2 mystery (HELP needed)

[Michael]

I am a bit puzzled as to how to setup new FFS in RDB

Now we have a few FFS to choose from.
1. Rom based v40.1
2. 3.9 version v45.16
3. 4.0 version v51.10
4. 4.1 version v52.6

Historically, I have a few hard drives an all of them are partitioned in many logical units with different file systems.

In theory the last FFS2 (52.6) is compatible with all the previous versions.
But if we follow the instructions and give it DOS\7 type when installed in RDB and remove all other FFS versions some of my partitions become NDOS.
If I install FFS2 (52.6) as DOS\3 all partitions are visible, and I can still format a DOS\7 file system if I select long file name support during format.
But this is supposed to be wrong according to the docs.

This also confuses me, should we have all versions of FFS installed in RDB
or just FFS2 (52.6) but in several dos types (copies for DOS\1, DOS\3, DOS\7)

The other mystery, is SCOUT showing info for partitions:
eg: filesystem as DOS\3 and DiskType as DOS\1
eg: filesystem as DOS\3 and DiskType as DOS\7
But probably it should be the same type in both fields.

Also when you try to version a device: it reports the version
of ffs in use, some report as 40.1, some as 45.16 and others as 52.6
but you would probably think that all of them should use the latest version.

Can somebody please elaborate the subject in a bit more detailed manor,
I could not find anything that explained this new situation with FFS.

[Cymru]

I can't elaborate beyond being a user: Use 45.16 for OS 3.X as Dos/7 (long file names won't be recognized by KS3.1). Don't use OS4.0 for anything.

[gulliver]

Originally Posted by Cymru

I can't elaborate beyond being a user: Use 45.16 for OS 3.X as Dos/7 (long file names won't be recognized by KS3.1). Don't use OS4.0 for anything.

There is a long readme on the OS4 cdrom about Olaf Barthel´s implementation of FFS on OS4. Read it. But, let me sumarize that you will have a slower FFS, with some few really minor backwards incompatibilities. On the good side, it supports longer filenames. But anyway, if you want a better filesystem just use PFS3 or the 45.xx version.

[Cymru]

Er, I think I came to the same conclusion. PFS3 (I use the AIO version) doesn't improve transfer speed and if it gets screwed up, the PFSDoctor program is pretty useless. If you keep FFS partitions <4GB, you can recover almost completely.

[Michael]

I have done some tests and got some interesting results

FFS 45.16
FFS2-test1.png

1. FFS 45.16 block 1024, buffers 500 - FASTEST
2. FFS 45.16 block 512, buffers 80 - default
3. FFS 45.16 block 1024, buffers 80 - better
4. FFS 45.16 block 1024, buffers 500
5. FFS 52.6 block 1024, buffers 500 (fastest FFS2)

Block size effects the speeds a little, but setting a good buffer makes a huge difference to some test (Dir Scan and Delete).
FFS2 performance on file delete is a mega surprise, pathetically slow
and file creation speed is not very good either.

One test missing from picture is FFS 45.16 block 512, buffers 500
the results are close to FFS 45.16 block 1024, buffers 500
just a bit slower, only open file is x2 times faster with 1024 block size (I wonder why)


FFS2 52.6
FFS2-test2.png

1. FFS 45.16 block 1024, buffers 500 - FASTEST
2. FFS 52.6 block 512, buffers 80 - default DOS/3
3. FFS 52.6 block 512, buffers 80 - default DOS/7
4. FFS 52.6 block 1024, buffers 80 - much better
5. FFS 52.6 block 1024, buffers 500 (fastest FFS2)

This shows that FFS2 with block 512 is totally unusable and slow
and it does benefit from 1024 blocks a lot. (Create File 3 - 4 times better!)
And write file is 2 times better with a large buffer.

Please ignore the last raw read test, it jumps from test to test a bit, should be 7.80 in all of them.


VERDICT: FFS2 is useful only for long file names support, and it does need to improve file delete speed, or maybe the test tool works oddly with it.

Now I guess I know why it is recommended to install it as DOS/7
so that it does not operate on lower type disks.

The other thing I have noticed just now! Is that you have to have
FFS in RDB of each HDD, if you want to use that particular version
with the partition on that drive, otherwise it can be the ROM based FFS

[Michael]

By the way v51.10 is actually slightly faster then v52.6 in some tests.

[Cymru]

If disk speed is defined as actual data transfer, then this is tied to the bus speed. How much of a directory is cached in a RAM buffer is not disk speed. Block size has two implications: How much is read during a rotation (of the track under the head, with larger being faster) and the smallest block size to fit a file on a disk compared to the space wasted (with less disk waste with smaller blocks). The detailed explanations of both can be found elsewhere.

In summary, the larger block read into the on-drive buffer, the quicker the data is ready for transfer to the bus, BUT the inefficiency of the larger block size (also if it exceeds the buffer) the negative trade off of the two. Confound this by the amount of file system "overhead" for error correction, file location then access (fragmentation), and whatnot. You then end up with figures that apply only to each specific hard drive, specific bus, and specific CPU for each specific file system.

Sound confusing? Just wait for more input (yes, Thomas, I mean you). It is just getting started! See Wallace Shawn rant in, "The Princess Bride."