From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 21:32:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5C7616DCF2 for ; Thu, 8 Jun 2006 18:10:29 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADEA043D4C for ; Thu, 8 Jun 2006 18:10:26 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id c31so384836nfb for ; Thu, 08 Jun 2006 11:10:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=Cf8DQExhnIKIpPecm7rYaFUT4EIfM4Im+Yq2wql+XreVcxaiYzf5VyYAaTcmZtsA3MOccL6PEM4X/NQ2UJJr0xPxarEYaWnC9pl2IXItmAcDm86rODqvXipo5h6oTi7cVpBsUofo6LbfcBy+GgEQKpZuVyLtG9Z93riQ7im3rYQ= Received: by 10.49.7.1 with SMTP id k1mr1587281nfi; Thu, 08 Jun 2006 11:10:23 -0700 (PDT) Received: from roadrunner.q.local ( [217.185.114.19]) by mx.gmail.com with ESMTP id p45sm2350999nfa.2006.06.08.11.10.17; Thu, 08 Jun 2006 11:10:22 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.6/8.13.6) with ESMTP id k58IALrN003592; Thu, 8 Jun 2006 20:10:21 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.6/8.13.6/Submit) id k58HfDKR003156; Thu, 8 Jun 2006 19:41:13 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Thu, 8 Jun 2006 19:41:13 +0200 From: Ulrich Spoerlein To: Pawel Jakub Dawidek Message-ID: <20060608174113.GC1075@roadrunner.q.local> Mail-Followup-To: Pawel Jakub Dawidek , freebsd-current@FreeBSD.org References: <20060608132048.GD86198@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline In-Reply-To: <20060608132048.GD86198@garage.freebsd.pl> Cc: freebsd-current@FreeBSD.org Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:32:12 -0000 --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > One of the main design goals was to make it reliable and resistant to > power failures or system crashes. This was very important to commit both > data update and HMAC update as an atomic operation to the disk, so users > don't have to fight with false positives. Great stuff. I take this opportunity to hijack this thread and ask I question that has been bothering me a long time now. I have an external HDD that I initially attached via Firewire, but I've since switched to USB, as our firewire subsystem is less than rock solid. When configuring geli encryption on the drive, I made the folly of using 4kB sectors, as this should improve performance. But, it has a disastrous impact on data integrity if your system crashes. Now, I don't know if I'm right with the following thoughts, so please correct me if I'm wrong. Consider an mtime or atime update. You need to update 4 bytes on the disk, which will be accomplished by writes of 512 bytes. If the system crashes in between (I'm not talking about power failures), the disk has either updated the 512 bytes, or not. No harm done. With 4096 byte sectors and unencrypted data, the hard disk will have written/updated 512 or 1024, ... or the whole 4096 bytes. Since only 4 bytes needed to be changed, you either got these changes or not. No harm done. Now consider encryption with 4096 byte sectors. Whenever you twiddle one bit, the whole 4096 byte sector changes completely. To leave the disk in a consistent state, you always have to make sure, that the whole 8 512-byte blocks are written to disk. If only a single 512-byte block is not updated (due to kernel crashing because of that !@#^#$@ firewire), the whole 4096 are useless. SoL. The question really is, are 512 byte disk writes considered to be some kind of "atomic" as it is the smallest disk block size? What does the ATA subsystem do with writes of 4096? Are they completed atomically too, or not? Due to various kernel panics (no power failures involved!) I lost several blocks of inodes on a 4096 byte sector geli mount. It's really no fun, if fsck tells you that inodes 102340 - 109329 are lost. Please note that I'm not asking any action from you, I'd simply appreciated it, if someone could confirm or dispute my claims. Thanks. Ulrich Spoerlein --=20 PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEiGE4524iJyD+6d0RAnDSAJ93ssmz6IU/ReSzpA8YHS2XcV9P9gCfZC76 HNFrXDfLTN5IUh7NSYp3L1k= =9NE1 -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef--