PFS3 block size

[Piru]

what the best block size is for this filesystem?

512 bytes

[Piru]

Surely this really depends on the modal average file size of files under say 8KB and the size the device is optimised for rather than a stock answer?

No, it doesn't.

Note: I answered the question.

[Piru]

I think you might have missed my second edit - I was referring to file systems in general (in the context Amiga file systems).

The absolute answer you questioned was the only correct answer to the question presented.

Regarding blocksize: Using large blocksize to gain performance only makes sense with poor filesystems that don't keep the data sequental (and thus don't perform mostly sequental access), or with hardware that actually uses larger hardware block size.

FFS is notoriously slow so with that you get a performance boost.

PS. While some amiga file systems allow 4k block sizes (and thus seem to be ready for the new 4k block size hard drives) there still is the issue of proper alignment. In order to obtain best performance the partition beginning must be aligned by the block size, too. I doubt the Amiga partitioning programs account for this.

[Piru]

Since block size is a minimum unit size you are also discussing the impact on the CPU and the amount of usable data transferred in a given time.

How? How is it different to transter 64 blocks of 512 bytes vs 32 blocks of 1024 bytes?

An extreme example - if the average file size being read is 1K and a cluster size is 8K (thus transfer block size) it'll be transferring more slack space than say with a block of 4K, plus the CPU will be doing more redundant IO operations  (CRC, reads etc).

Why would the filesystem read the whole 8K in this case? Even if it would read the whole 8k, modern drives are so fast in sequental access that it makes little difference if you read 1k or 8k.

What CRC are you talking about? If it's something in the filesystem (no amiga filesystem CRCs the data btw), why would the filesystem calculate CRC for the whole 8k if only 1k is of is valid data? Lets not forget that most time is spent reading and writing the data. Metadata is insignificant in comparison.

This probably doesn't matter for compact flash which has a standardised sector of 512B so I guess that part answers my initial question as to the best size for CF, either 512B or 1K

It was about the new 4k hard disk drives which report 512k block size (for compatibility reasons) while actually using 4k block sizes internally. They do work, but writing gets really slow of the block is not aligned properly. Until recently both Windows and Linux created such bad partitioning.

As for flash, they have a totally different internal structure which the typical filesystem has no way of knowing. The firmware tries to do some magic tricks to accomodate for the silly things typical filesystems do when they assume classical HDD. There's little that can be assumed about flash, except that small writes are typically really slow (due to flash internal arrangement).

http://en.wikipedia.org/wiki/UBIFS is an interesting approach to the problem. Rather than going thru the firmware, access the flash directly. Obviously this requires special HW (that is: it's not usable with your off-the-shelf SSD drives). Here's some more about UBIFS: http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf

[Piru]

As reminded by a friend: AmigaOS is one of the few OSes that don't do proper block level caching by itself. This is another reason by large block size gives benefit with FFS.

It has gone as far as some filesystems implementing such caching, read ahead etc in itself (SFS).

[Piru]

I've tried PFS in the past but I much prefer to use SmartFileSystem myself. I'ts very easy to use and set up, no problems with block sizes or such like. Been using it for about 4 to 5 years now and have never lossed a single bit of data.

The sad thing about SFS is that it's inferior compared to PFS3, regardless of SFS being much later development.

• PFS3 is faster than SFS.
• PFS3 doesn't generate massively fragmented files when two or more applications write files to disk. SFS does.
• PFS3 performance doesn't deteriorate over time. SFS does.
• PFS3 has a repair tool. Often with SFS the only option is to copy data over, reformat and copy data back (MorphOS does have a SFSDoctor tool, however).

[Piru]

SFS being inferior is just your opinion

Benchmarks are out there, PFS3 is a lot faster than SFS. It's easy to reproduce the fragmentation issue by having multiple apps writing a file on SFS volume at the same time, and to verify the excessive fragmentation that results. Performance deterioration over time is a bit trickier to test, but most likely it's a direct result from the fragmentation issue described, but other factors can be in play as well. The issue has been observed by many (more than just me). Lack of repair tool (for anything but MorphOS) is a fact, too.

It's more than just an opinion.

I've been using it for years, and both of my 500GB HDs are almost full. I've never noticed any performance deterioration or ever had the need to repair any files or partions.

You're extremely lucky.