Re: [zfs-discuss] When is it okay to turn off the "verify" option.

2010-10-04 Thread Edward Ned Harvey
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Scott Meilicke
> 
> Why do you want to turn verify off? If performance is the reason, is it
> significant, on and off?

Under most circumstances, verify won't hurt performance.  It won't hurt
reads of any kind, and it won't hurt writes when you're writing unique data,
or if you're writing duplicate data which is "warm" in the read cache.  

It will basically hurt write performance if you are writing duplicate data,
which was not read recently.  This might be the case, for example, if this
machine is the target for some remote machine to backup onto.

The problem doesn't exist if you're copying local data, because you first
read the data (now it's warm in cache) before writing it.  So the verify
operation is essentially zero time in that case.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] When is it okay to turn off the "verify" option.

2010-10-04 Thread Scott Meilicke
Why do you want to turn verify off? If performance is the reason, is it 
significant, on and off?

On Oct 4, 2010, at 2:28 PM, Edward Ned Harvey wrote:

>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>> boun...@opensolaris.org] On Behalf Of Peter Taps
>> 
>> As I understand, the hash generated by sha256 is "almost" guaranteed
>> not to collide. I am thinking it is okay to turn off "verify" property
>> on the zpool. However, if there is indeed a collision, we lose data.
>> "Scrub" cannot recover such lost data.
>> 
>> I am wondering in real life when is it okay to turn off "verify"
>> option? I guess for storing business critical data (HR, finance, etc.),
>> you cannot afford to turn this option off.
> 
> Right on all points.  It's a calculated risk.  If you have a hash collision,
> you will lose data undetected, and backups won't save you unless *you* are
> the backup.  That is, if the good data, before it got corrupted by your
> system, happens to be saved somewhere else before it reached your system.
> 
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Scott Meilicke



___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] When is it okay to turn off the "verify" option.

2010-10-04 Thread Edward Ned Harvey
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Peter Taps
> 
> As I understand, the hash generated by sha256 is "almost" guaranteed
> not to collide. I am thinking it is okay to turn off "verify" property
> on the zpool. However, if there is indeed a collision, we lose data.
> "Scrub" cannot recover such lost data.
> 
> I am wondering in real life when is it okay to turn off "verify"
> option? I guess for storing business critical data (HR, finance, etc.),
> you cannot afford to turn this option off.

Right on all points.  It's a calculated risk.  If you have a hash collision,
you will lose data undetected, and backups won't save you unless *you* are
the backup.  That is, if the good data, before it got corrupted by your
system, happens to be saved somewhere else before it reached your system.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss