In article ,
The Natural Philosopher writes:
On 13/02/16 00:08, Andrew Gabriel wrote:
In article ,
The Natural Philosopher writes:
On 07/02/16 12:36, Andrew Gabriel wrote:

Depends what data availability you need. The cost of mirroring is worth
it for me - if a disk dies in the middle of my work, I don't have to
stop work and go and fix it.


that is fair enough, but then you have top replace it with a new one of
the same basic type.

With ZFS, the new disk needs to have a sector size = the other disk,
and number of sectors = other disk. Other than that, it doesn't care.
If the new disk is bigger, the excess isn't used unless/until you replace
the other disk with a bigger one too.

Isn't ZFS the file system that if you are unlucky, borks itself beyod
all repair possibility, even on RAID?

It's pretty difficult to do.
In the early days, it was liable to IDE disks lying about when they
had really committed blocks to disk which hit some home users, but a
feature was added to enable ZFS to backstep through the transaction
commits to find the last one where the disk had really committed all
the i/o, when it has lied about performing later commits and then lost
the data at poweroff. I haven't heard of SATA drives lying about write
commits, and everyone who uses ZFS at large scale will be using SAS
disks which have much better quality firmware anyway.

I've worked with many hundreds of customers using ZFS, and none have
ever lost any data due to it. It's clearly not impossible if you are
stupid enough and some people are, but in general it's much less likely
than on other filesystems. Above all, you do know when data is corrupt,
which is not the case with most filesystems. Many customers have layered
ZFS on top of their expensive SAN storage arrays so they can tell when
data gets corrupted, which was something that previously usually went
unnoticed until it was too late to restore an uncorrupted copy.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]