From owner-freebsd-fs@FreeBSD.ORG Fri Apr 24 06:45:32 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 85861106564A for ; Fri, 24 Apr 2009 06:45:32 +0000 (UTC) (envelope-from scott@bqinternet.com) Received: from mail.bqinternet.com (mail.bqinternet.com [69.9.32.203]) by mx1.freebsd.org (Postfix) with ESMTP id 5BDDC8FC24 for ; Fri, 24 Apr 2009 06:45:32 +0000 (UTC) (envelope-from scott@bqinternet.com) Received: from localhost (mail [69.9.32.203]) by mail.bqinternet.com (Postfix) with ESMTP id 71249409A04; Fri, 24 Apr 2009 06:45:32 +0000 (GMT) Received: from mail.bqinternet.com ([69.9.32.203]) by localhost (mail.bqinternet.com [69.9.32.203]) (amavisd-new, port 10024) with ESMTP id Vz7gJ+9uzqgO; Fri, 24 Apr 2009 06:45:31 +0000 (GMT) Received: from scott-burnss-macbook-air.local (mail [69.9.32.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bqinternet.com (Postfix) with ESMTP id 1F54A409A61; Fri, 24 Apr 2009 06:45:31 +0000 (GMT) Message-ID: <49F16009.3080206@bqinternet.com> Date: Fri, 24 Apr 2009 02:45:29 -0400 From: Scott Burns User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexander Kabaev References: <49F048FB.6000401@bqinternet.com> <20090423195335.521db0a7@kan.dnsalias.net> In-Reply-To: <20090423195335.521db0a7@kan.dnsalias.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 06:45:32 -0000 Alexander Kabaev wrote: > On Thu, 23 Apr 2009 06:54:51 -0400 > Scott Burns wrote: > >> Hi guys, >> >> I have spent some time writing a kernel module which calculates a >> 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). >> >> 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. >> >> I'm aware that data integrity issues are addressed with ZFS, but >> unfortunately ZFS is still not yet suitable for many workloads. I'm >> 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. >> >> Before I spend much more time on it, I have some questions: >> >> 1) Has anyone else done any work in this area? >> >> 2) Is there a demand for this in FreeBSD? >> > > 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 As long as there is some interest in this kind of functionality, I will continue working on it. The next step is to protect metadata structures beyond inodes. I am hoping to have some results to post in the next few weeks. -- Scott Burns System Administrator BQ Internet Corporation