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

[Peter Jeremy]

On 2013-Jan-21 12:12:45 +0100, Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl> wrote:
>That's why i use properly tuned UFS, gmirror, and prefer not to use 
>gstripe but have multiple filesystems

When I started using ZFS, I didn't fully trust it so I had a gmirrored
UFS root (including a full src tree).  Over time, I found that gmirror
plus UFS was giving me more problems than ZFS.  In particular, I was
seeing behaviour that suggested that the mirrors were out of sync,
even though gmirror insisted they were in sync.  Unfortunately, there
is no way to get gmirror to verify the mirroring or to get UFS to
check correctness of data or metadata (fsck can only check metadata
consistency).  I've since moved to a ZFS root.

>Which is marketing, not truth. If you want bullet-proof recoverability, 
>UFS beats everything i've ever seen.

I've seen the opposite.  One big difference is that ZFS is designed to
ensure it returns the data that was written to it whereas UFS just
returns the bytes it finds where it thinks it wrote your data.  One
side effect of this is that ZFS is far fussier about hardware quality
- since it checksums everything, it is likely to pick up glitches that
UFS doesn't notice.

>If you want FAST crash recovery, use softupdates+journal, available in 
>FreeBSD 9.

I'll admit that I haven't used SU+J but one downside of SU+J is that
it prevents the use of snapshots, which in turn prevents the (safe)
use of dump(8) (which is the official tool for UFS backups) on live
filesystems.

>> of fuss.  Even if you dislodge a drive ... so that it's missing the last
>> 'n' transactions, ZFS seems to figure this out (which I thought was extra
>> cudos).
>
>Yes this is marketing. practice is somehow different. as you discovered 
>yourself.

Most of the time this works as designed.  It's possible there are bugs
in the implementation.

>While RAID-Z is already a king of bad performance,

I don't believe RAID-Z is any worse than RAID5.  Do you have any actual
measurements to back up your claim?

> i assume 
>you mean two POOLS, not 2 RAID-Z sets. if you mixed 2 different RAID-Z pools you would 
>spread load unevenly and make performance even worse.

There's no real reason why you could't have 2 different vdevs in the
same pool.

>> A full scrub of my drives weighs in at 36 hours or so.
>
>which is funny as ZFS is marketed as doing this efficient (like checking 
>only used space).

It _does_ only check used space but it does so in logical order rather
than physical order.  For a fragmented pool, this means random accesses.

>Even better - use UFS.

Then you'll never know that your data has been corrupted.

>For both bullet proof recoverability and performance.
use ZFS.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20130122/9cdd2beb/attachment.sig>