Nicolas Williams wrote:
> On Tue, Oct 20, 2009 at 10:51:29AM +0100, Darren J Moffat wrote:
>   
>> Glad that you do offer verify as a choice.   It would be very useful to 
>> provide some sort of log output for the cases where verify found a 
>> collision - ie the checksum hashes matched but the verify said they were 
>> different.  Not useful to end users so it could be a DTrace SDT or only 
>> in a DEBUG kernel.  If this ever shows up a "hit" when 
>> dedup=sha256,verify it will make ZFS famous for finding collisions in 
>> SHA256.
>>     
>
> A collision log for debug purposes would be nice.  But collision stats
> should be provided in any case because such stats can be useful to
> estimitating the usefulness of a hash function for this purpose (how
> much time is spent computing hashes vs. how much time is spent verifying
> blocks, and how many blocks do collide).
>
> Collision stats could also be a useful way to build confidence in a hash
> function ("look! 0 collisions for SHA-3 candidate X on a 1PB pool with
> random and real data!").  Of course, a SHA-3 candidate must build
> confidence by surviving known cryptanalysis techniques + any new ones
> that cryptographers throw at it, and no collisions in 1PB hardly
> constitutes proof, but N>0 collisions in 1PB would be likely be
> worrisome and indicative that additional analysis is needed.  Yes, a
> flight of fancy, maybe just eye candy ("ah, SHA-256 seems to be working
> as advertised"), but if so, it'd be cheap eye candy.
>
> % zpool get ddhashcolls,ddcollrate rpool
> NAME   PROPERTY       VALUE                     SOURCE
> rpool  ddhashcolls    5                         -
> rpool  ddcollrate     .0135                     -
> % 
>
> (One prop would count total collisions ever seen, the other would be a
> ration of the first and the pool size.)
>   

How about just a kstat where it can be located easily for debug, without 
polluting normal zfs properties?

    - Garrett
> Nico
>   

Reply via email to