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 15:32:05 +0200 Message-ID: <20070502133205.GB20776@lazybastard.org> References: <20070428220522.GN11166@waste.org> <20070429232349.GA19937@thunk.org> <20070430014042.GL11115@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]:36939 "EHLO longford.lazybastard.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993179AbXEBNgM (ORCPT ); Wed, 2 May 2007 09:36:12 -0400 Content-Disposition: inline In-Reply-To: <20070430014042.GL11115@waste.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, 29 April 2007 20:40:42 -0500, Matt Mackall wrote: >=20 > So we should have no trouble checking an exabyte-sized filesystem on = a > 4MB box. Even if it has one exabyte-sized file! We check the first > tile, see that it points to our file, then iterate through that file, > checking that the forward and reverse pointers for each block match > and all CRCs match, etc. We cache the file's inode as clean, finish > checking anything else in the first tile, then mark it clean. When we= get > to the next tile (and the next billion after that!), we notice that > each block points back to our cached inode and skip rechecking it. How would you catch the case where some block in tile 2 claims to belon= g to your just-checked inode but the inode has no reference to it? How would you catch the inode referencing the same block twice with jus= t 4MB of memory? I believe you need the fpos field in your rmap for both problems. J=C3=B6rn --=20 Anything that can go wrong, will. -- Finagle's Law - 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