ZFS regimen: scrub, scrub, scrub and scrub again.

[Wojciech Puchar]

>
> That's a bold statement. Literally. :-)

And literally tested. But few settings have to be changed, and are for 
unknown reason capped on bad values for years. I will not repeat it as i 
already wrote it many times.

If you like real results - i am getting like 50MB/s total I/O 
throughput when reading 10 different files in parallel on my really low 
speed laptop disk. It can do at most 69MB/s from the outer surface 
tested by dd if=/dev/ada0 of=/dev/null bs=2m

100MB/s are normal for modern 7200rpm SATA disks.

UFS have weak points like lots of small files, but except writing, or 
reading already cached things, it is still faster than ZFS.

That's about speed. As for reliability i already explained it.

UFS can be improved. Best improvement would be SSD caching for metadata 
and selected data.

But something real, not L2ARC or dragonflybsd's swapcache.

A moment when you need high performance the most is after failure. When 
all people waited for system being up and then - at once - like to use it.
In this moment L2ARC is empty and give no help.
SSD cache must be persistent.

Another improvement would be adding, after user quota and group quota, 
jail quota and jail ID in metadata. Not that useful for me, but may be 
useful for people that serve 1000s of random unknown clients.

Things like snapshots and pseudo filesystems are cool but not really that 
useful, at least for me. And when using it heavily one will quickly get 
lost in the mess.


> However, it appears that we're nowhere near having a rational discussion:
> http://thoughtcatalog.com/2011/how-to-have-a-rational-discussion/
>
true. And it will not change until technical arguments will be the only 
arguments. Not fanatic reactions or repeating marketing words.

ZFS is great marketer tool. It promises features that would make 
administering a server very easy at first.
Then - there are companies for data recovery :) I wish them a lots of 
money earned.