From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Mackall Subject: Re: [RFC] TileFS - a proposal for scalable integrity checking Date: Sun, 29 Apr 2007 11:24:30 -0500 Message-ID: <20070429162430.GI11115@waste.org> References: <20070428220522.GN11166@waste.org> <20070429155847.GC30608@lazybastard.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org To: =?iso-8859-1?Q?J=F6rn?= Engel Return-path: Received: from waste.org ([66.93.16.53]:37209 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756515AbXD2QYp (ORCPT ); Sun, 29 Apr 2007 12:24:45 -0400 Content-Disposition: inline In-Reply-To: <20070429155847.GC30608@lazybastard.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, Apr 29, 2007 at 05:58:48PM +0200, J=F6rn Engel wrote: > On Sat, 28 April 2007 17:05:22 -0500, Matt Mackall wrote: > >=20 > > Some things we need to check during fsck: > >=20 > > all directories point to in-use inodes > > all in-use inodes are referred to by directories > > all inodes in use are marked in use > > all free inodes are marked free > > all inodes point to in-use blocks > > all inode refcounts are correct > > all inode block counts are correct > > free inode count is correct > >=20 > > no blocks are used twice > > all used blocks are marked as used > > all free blocks are marked as free > > optional: all block contents are correct >=20 > statfs information matches filesystem content >=20 > This one may still require a full fsck in your current approach. One= if > the good aspects of ChunkFS (assuming my understanding matches realit= y) > is to have per-chunk counters for free blocks, free inodes, etc. For= a > fast fsck you would need to have these counters per-unit as well. It > doesn't matter whether your unit is a tile, chunk, blockgroup or > karboozel. Yes. This is probably not a very big problem. Once we've checked all the tiles in a block group and they're clean, we know that block and inode bitmaps are correct, so we can doublecheck the per-blockgroup counters. One obvious approach is simply batching a blockgroup's worth of tiles at a time (if tile header entries are 64 bits, then there are 64 tiles in a block group). Then you keep running totals and check at the end. Memory usage is still O(single tile). Summing blockgroup totals across a million block groups.. we'll probably want something like: > Having some tree structure for these counters would also help. Statf= s > requires to add all counters for all units. Smaller units speed up f= sck > but slow down statfs. With a tree statfs can be O(log(n)). --=20 Mathematics is the supreme nostalgia of our time. - 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