From owner-freebsd-bugs@FreeBSD.ORG Fri Aug 29 17:17:55 2014 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4324D179 for ; Fri, 29 Aug 2014 17:17:55 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 233061A36 for ; Fri, 29 Aug 2014 17:17:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7THHtvY052377 for ; Fri, 29 Aug 2014 17:17:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 193124] New: GELI data integrity verification should consider sparse zero pass-through Date: Fri, 29 Aug 2014 17:17:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: 5ukk2nmn43@snkmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 17:17:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193124 Bug ID: 193124 Summary: GELI data integrity verification should consider sparse zero pass-through Product: Base System Version: 10.0-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: 5ukk2nmn43@snkmail.com GEOM geli data authentication (option -a) verifies data integrity of the blocks on a device. The current implementation requires that the entire device be written before it can be read from. There's a note on this in the geli(8) man page. I'd like to consider the use case where the device is sparse - whether it's a sparse file backed block device, an SSD with TRIM, or even just a really big hard drive that hasn't been written to yet. In this case, writing to the device in order to compute checksums would take quite a bit of time with a big device, and also would consume resources to store that data, especially if the underlying layer that detects a sparse sector doesn't align with the integrity information. When the underlying data in a sector is all zeroes (or is presumed to be all zeroes if it's unwritten or sparse), perhaps the verification layer should let the checksum be artificially produced as all zeroes too. In terms of hashing, there shouldn't be any risk in plucking out one output hash (consisting of all zeroes) from a pool of 2^256 or more, since it's impractical to find any true data source that hashes to that. The GEOM integrity layer most likely is used only on FreeBSD so there may not be a need to have the checksum algorithm perfectly match. Maybe this can be a sysctl parameter or an option to geli. I'd propose that any time a particular sector has all zeroes, then the checksum written to (and verified against) should also be zeroes. This would effectively give the intended benefits desired in integrity verification but would make a difference even in the case of a traditional hard drive. Instead of having to take hours or even days to write out the checksums to new drives, it would be instantly available. For a drive (or sparse image) that is not all zeroes, then there's really no way around needing to write those sectors. -- You are receiving this mail because: You are the assignee for the bug.