From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?SsO2cm4=?= Engel Subject: Re: [RFC] TileFS - a proposal for scalable integrity checking Date: Wed, 2 May 2007 18:35:41 +0200 Message-ID: <20070502163540.GA22671@lazybastard.org> References: <20070428220522.GN11166@waste.org> <20070429232349.GA19937@thunk.org> <20070430014042.GL11115@waste.org> <20070502133205.GB20776@lazybastard.org> <20070502153738.GJ11115@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Theodore Tso , linux-fsdevel@vger.kernel.org To: Matt Mackall Return-path: Received: from lazybastard.de ([212.112.238.170]:34852 "EHLO longford.lazybastard.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993500AbXEBQjz (ORCPT ); Wed, 2 May 2007 12:39:55 -0400 Content-Disposition: inline In-Reply-To: <20070502153738.GJ11115@waste.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2 May 2007 10:37:38 -0500, Matt Mackall wrote: >=20 > fpos does allow us to check just a subset of the file efficiently, > yes. And that things are more strictly 1:1, because it unambiguously > matches a single forward pointer in the file. Ok, I'm warming to the > idea. >=20 > But indirect blocks don't have an fpos, per se. They'd need a special > encoding. As the fpos entries will all be block aligned, we'll have 1= 2 > extra bits to play with, so that may be easy enough. No special encoding is needed. LogFS uses the fpos of some block behin= d that indirect block. It doesn't even matter which one. When checking the block, the indirect block has to get touched while trying to get to the alledged fpos. As already explained, LogFS also encodes the level (data, indirect, doubly indirect, etc.). If you want to play games with extra bits, you could do the same. Two bits should be sufficient for ext2. The only thing the level buys you for TileFS is to detect writes to the wrong address, where wrong address and correct address match in (ino, fpos), but not in level. > It's a bit frustrating to have 96-bit (inode+fpos) pointers in one > direction and 32-bit (blockno) pointers in the other though. This > doubles the overhead to .4%. Still not fatal - regular ext2 overhead > is somewhere between 1% and 3% depending on inode usage. My ext3 root partition currently wastes 60 Bytes per block on unused inodes. If space was an issue, adding an inode file to to TileFS would help more than trying to squeeze bits from the rmap. J=C3=B6rn --=20 /* Keep these two variables together */ int bar; - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html