LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Al Boldi <a1426z@gawab.com>
To: "Valerie Henson" <val.henson@gmail.com>
Cc: "Rik van Riel" <riel@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFD] Incremental fsck
Date: Wed, 9 Jan 2008 14:52:14 +0300 [thread overview]
Message-ID: <200801091452.14890.a1426z@gawab.com> (raw)
In-Reply-To: <70b6f0bf0801082345vf57951ey642e35c3d6e5194f@mail.gmail.com>
Valerie Henson wrote:
> On Jan 8, 2008 8:40 PM, Al Boldi <a1426z@gawab.com> wrote:
> > Rik van Riel wrote:
> > > Al Boldi <a1426z@gawab.com> wrote:
> > > > Has there been some thought about an incremental fsck?
> > > >
> > > > You know, somehow fencing a sub-dir to do an online fsck?
> > >
> > > Search for "chunkfs"
> >
> > Sure, and there is TileFS too.
> >
> > But why wouldn't it be possible to do this on the current fs
> > infrastructure, using just a smart fsck, working incrementally on some
> > sub-dir?
>
> Several data structures are file system wide and require finding every
> allocated file and block to check that they are correct. In
> particular, block and inode bitmaps can't be checked per subdirectory.
Ok, but let's look at this a bit more opportunistic / optimistic.
Even after a black-out shutdown, the corruption is pretty minimal, using
ext3fs at least. So let's take advantage of this fact and do an optimistic
fsck, to assure integrity per-dir, and assume no external corruption. Then
we release this checked dir to the wild (optionally ro), and check the next.
Once we find external inconsistencies we either fix it unconditionally,
based on some preconfigured actions, or present the user with options.
All this could be per-dir or using some form of on-the-fly file-block-zoning.
And there probably is a lot more to it, but it should conceptually be
possible, with more thoughts though...
> http://infohost.nmt.edu/~val/review/chunkfs.pdf
Thanks!
--
Al
next prev parent reply other threads:[~2008-01-09 11:55 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 21:22 Al Boldi
2008-01-08 21:31 ` Alan
2008-01-09 9:16 ` Andreas Dilger
2008-01-12 23:55 ` Daniel Phillips
2008-01-08 21:41 ` Rik van Riel
2008-01-09 4:40 ` Al Boldi
2008-01-09 7:45 ` Valerie Henson
2008-01-09 11:52 ` Al Boldi [this message]
2008-01-09 14:44 ` Rik van Riel
2008-01-10 13:26 ` Al Boldi
2008-01-12 14:51 ` Theodore Tso
2008-01-13 11:05 ` Al Boldi
2008-01-13 17:19 ` Pavel Machek
2008-01-13 17:41 ` Alan Cox
2008-01-15 20:16 ` [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck) Pavel Machek
2008-01-15 21:43 ` David Chinner
2008-01-15 23:07 ` Pavel Machek
2008-01-15 23:44 ` Daniel Phillips
2008-01-16 0:15 ` Alan Cox
2008-01-16 1:24 ` Daniel Phillips
2008-01-16 1:36 ` Chris Mason
2008-01-17 20:54 ` Pavel Machek
2008-01-16 19:06 ` Bryan Henderson
2008-01-16 20:05 ` Alan Cox
2008-01-17 2:02 ` Daniel Phillips
2008-01-17 21:37 ` Bryan Henderson
2008-01-17 22:45 ` Theodore Tso
2008-01-17 22:58 ` Alan Cox
2008-01-17 23:18 ` Ric Wheeler
2008-01-18 0:31 ` Bryan Henderson
2008-01-18 14:23 ` Theodore Tso
2008-01-18 15:16 ` [Patch] document ext3 requirements (was Re: [RFD] Incrementalfsck) linux-os (Dick Johnson)
2008-01-19 14:53 ` Pavel Machek
2008-01-18 15:26 ` [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck) Ric Wheeler
2008-01-18 20:34 ` Jeff Garzik
2008-01-18 22:35 ` Bryan Henderson
2008-01-18 15:08 ` H. Peter Anvin
2008-01-18 17:43 ` Bryan Henderson
2008-01-16 21:28 ` Eric Sandeen
2008-01-16 11:51 ` Pavel Machek
2008-01-16 12:20 ` Valdis.Kletnieks
2008-01-19 14:51 ` Pavel Machek
2008-01-16 16:38 ` Christoph Hellwig
2008-01-16 1:44 ` Daniel Phillips
2008-01-16 3:05 ` Rik van Riel
2008-01-17 7:38 ` Andreas Dilger
2008-01-16 11:49 ` Pavel Machek
2008-01-16 20:52 ` Valerie Henson
2008-01-17 12:29 ` Szabolcs Szakacsits
2008-01-17 22:51 ` Daniel Phillips
2008-01-15 1:04 ` [RFD] Incremental fsck Ric Wheeler
2008-01-14 0:22 ` Daniel Phillips
2008-01-09 8:04 ` Valdis.Kletnieks
[not found] <9JubJ-5mo-57@gated-at.bofh.it>
[not found] ` <9JB3e-85S-13@gated-at.bofh.it>
[not found] ` <9JDRm-4bR-1@gated-at.bofh.it>
[not found] ` <9JHLl-2dL-1@gated-at.bofh.it>
2008-01-11 14:20 ` Bodo Eggert
2008-01-12 10:20 ` Al Boldi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200801091452.14890.a1426z@gawab.com \
--to=a1426z@gawab.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
--cc=val.henson@gmail.com \
--subject='Re: [RFD] Incremental fsck' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).