From owner-freebsd-fs@FreeBSD.ORG Fri Apr 24 00:16:39 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A2631065678 for ; Fri, 24 Apr 2009 00:16:39 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id F00478FC12 for ; Fri, 24 Apr 2009 00:16:38 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so505885ana.13 for ; Thu, 23 Apr 2009 17:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=nzMxPN5X4vtkXBUE5WJRU1JYzmuQbZh4r4mDVTgMtQU=; b=b2CJb+/R+TuJiNZ/Vh5IWk8VsKcH2TK+Q/+lhVRw0n2OCXT2I2hkm6TEZOoQmZ/gV8 9sh7VLWuw2e13GREVATDV4WlKIDU3tkErmJjXIsTbmqdG+G74zY7TMLp2UOK5uqLdHdm VSeW6fNgYzaFRHXxkNHRKGRjTc/gMqVQkapxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=KIm+O7EO+G70o74FscFan0UiL1whhgAzW54FVFHzJVKM7Vdcxl8JcNxz6hr5NfbMba VEHr5kttcmzLguOUFi18tKor4UvF6T9r99jwZ9awPfyS53WXisbFEWbaSTktcHesTqAX J7kIn8A1L6/E/YYNAXEvlYHQyiEapnSllaO8g= Received: by 10.100.43.10 with SMTP id q10mr2209867anq.113.1240530825575; Thu, 23 Apr 2009 16:53:45 -0700 (PDT) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id c9sm1454514ana.19.2009.04.23.16.53.42 (version=SSLv3 cipher=RC4-MD5); Thu, 23 Apr 2009 16:53:43 -0700 (PDT) Date: Thu, 23 Apr 2009 19:53:35 -0400 From: Alexander Kabaev To: Scott Burns Message-ID: <20090423195335.521db0a7@kan.dnsalias.net> In-Reply-To: <49F048FB.6000401@bqinternet.com> References: <49F048FB.6000401@bqinternet.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/vUEWaOp4GWXxjRiu=mqaDuN"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 metadata checksums X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 00:16:39 -0000 --Sig_/vUEWaOp4GWXxjRiu=mqaDuN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 23 Apr 2009 06:54:51 -0400 Scott Burns wrote: > Hi guys, >=20 > I have spent some time writing a kernel module which calculates a=20 > checksum of a UFS2 dinode structure and stores it in the reserved > space of the inode when writing it to disk. It is then verified when > the inode is read from disk. If the checksum verification fails, the > read returns an error (currently EIO). >=20 > I believe that protecting metadata integrity is important, especially > as storage capacity grows. Bitrot is a fact of life, and bad things > can happen if the kernel acts on a corrupted inode. Not only does > this module improve the stability of a server, but it also helps to > prevent additional damage to the filesystem that can be caused by > metadata corruption. >=20 > I'm aware that data integrity issues are addressed with ZFS, but=20 > unfortunately ZFS is still not yet suitable for many workloads. I'm=20 > also aware that integrity checking can be done by using GELI between > the filesystem and the disk, but at a noticeable cost in performance > and space utilization. The method this module uses is fast and does > not use any additional space. Most importantly, it builds on mature > code that has worked well for decades. >=20 > Before I spend much more time on it, I have some questions: >=20 > 1) Has anyone else done any work in this area? >=20 > 2) Is there a demand for this in FreeBSD? >=20 This is actually something I would love to have in the base system, but inodes are not the only structures that need the integrity protection. Pretty much every other metadata block, from cylinder group blocks to indirect blocks for files need similar protection for this to be of real use. -- Alexander Kabaev --Sig_/vUEWaOp4GWXxjRiu=mqaDuN Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQFJ8P+EQ6z1jMm+XZYRAlf7AKDsiq2qamcMl6ZoRrBMM+by6xf3tACffWL3 wU6B/Po61UtBOiAZ3NSQfF0= =bZaN -----END PGP SIGNATURE----- --Sig_/vUEWaOp4GWXxjRiu=mqaDuN--