From owner-freebsd-bugs@FreeBSD.ORG Thu Jul 28 08:40:07 2011 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5ECD31065670 for ; Thu, 28 Jul 2011 08:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 36A0F8FC14 for ; Thu, 28 Jul 2011 08:40:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6S8e7Ol008499 for ; Thu, 28 Jul 2011 08:40:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6S8e7WP008498; Thu, 28 Jul 2011 08:40:07 GMT (envelope-from gnats) Resent-Date: Thu, 28 Jul 2011 08:40:07 GMT Resent-Message-Id: <201107280840.p6S8e7WP008498@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, vermaden Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCA2B106566C for ; Thu, 28 Jul 2011 08:31:14 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id ACCEA8FC0C for ; Thu, 28 Jul 2011 08:31:14 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p6S8VENL089750 for ; Thu, 28 Jul 2011 08:31:14 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p6S8VE7Y089749; Thu, 28 Jul 2011 08:31:14 GMT (envelope-from nobody) Message-Id: <201107280831.p6S8VE7Y089749@red.freebsd.org> Date: Thu, 28 Jul 2011 08:31:14 GMT From: vermaden To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/159251: FEATURE REQUEST: add FLETCHER4 as DEDUP hash option X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 08:40:07 -0000 >Number: 159251 >Category: kern >Synopsis: FEATURE REQUEST: add FLETCHER4 as DEDUP hash option >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Jul 28 08:40:06 UTC 2011 >Closed-Date: >Last-Modified: >Originator: vermaden >Release: 8.2-STABLE >Organization: >Environment: >Description: Hi, it would be nice to have fletcher4 as a faster alternative to sha256: # zfs set dedup=fletcher4,verify tank cannot set property for 'tank': 'dedup' must be one of 'on | off | verify | sha256[,verify]' FROM: http://blogs.oracle.com/bonwick/entry/zfs_dedup ---------------------------------------------------------------------- Given the ability to detect hash collisions as described above, it is possible to use much weaker (but faster) hash functions in combination with the 'verify' option to provide faster dedup. ZFS offers this option for the fletcher4 checksum, which is quite fast: # zfs set dedup=fletcher4,verify tank The tradeoff is that unlike SHA256, fletcher4 is not a pseudo-random hash function, and therefore cannot be trusted not to collide. It is therefore only suitable for dedup when combined with the 'verify' option, which detects and resolves hash collisions. On systems with a very high data ingest rate of largely duplicate data, this may provide better overall performance than a secure hash without collision verification. ---------------------------------------------------------------------- Regards, vermaden >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: