[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070425224349.GA16129@nifty>
Date: Wed, 25 Apr 2007 15:43:50 -0700
From: Valerie Henson <val_henson@...ux.intel.com>
To: Nikita Danilov <nikita@...sterfs.com>
Cc: David Lang <david.lang@...italinsight.com>,
Amit Gud <gud@....ksu.edu>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, riel@...riel.com, zab@...bo.net,
arjan@...radead.org, suparna@...ibm.com, brandon@...p.org,
karunasagark@...il.com, gud@....edu
Subject: Re: [RFC][PATCH] ChunkFS: fs fission for faster fsck
On Tue, Apr 24, 2007 at 11:34:48PM +0400, Nikita Danilov wrote:
>
> Maybe I failed to describe the problem presicely.
>
> Suppose that all chunks have been checked. After that, for every inode
> I0 having continuations I1, I2, ... In, one has to check that every
> logical block is presented in at most one of these inodes. For this one
> has to read I0, with all its indirect (double-indirect, triple-indirect)
> blocks, then read I1 with all its indirect blocks, etc. And to repeat
> this for every inode with continuations.
>
> In the worst case (every inode has a continuation in every chunk) this
> obviously is as bad as un-chunked fsck. But even in the average case,
> total amount of io necessary for this operation is proportional to the
> _total_ file system size, rather than to the chunk size.
Fsck in chunkfs is still going to have an element that is proportional
to the file system size for certain cases. However, that element will
be a great deal smaller than in a regular file system, except in the
most pathological cases. If those pathological cases happen often,
then it's back to the drawing board. My hunch is that they won't be
common.
-VAL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists