From: "Jörn Engel" <joern@lazybastard.org>
To: Matt Mackall <mpm@selenic.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] TileFS - a proposal for scalable integrity checking
Date: Sun, 29 Apr 2007 17:58:48 +0200 [thread overview]
Message-ID: <20070429155847.GC30608@lazybastard.org> (raw)
In-Reply-To: <20070428220522.GN11166@waste.org>
On Sat, 28 April 2007 17:05:22 -0500, Matt Mackall wrote:
>
> Some things we need to check during fsck:
>
> 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
>
> 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
statfs information matches filesystem content
This one may still require a full fsck in your current approach. One if
the good aspects of ChunkFS (assuming my understanding matches reality)
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.
Having some tree structure for these counters would also help. Statfs
requires to add all counters for all units. Smaller units speed up fsck
but slow down statfs. With a tree statfs can be O(log(n)).
Jörn
--
"Translations are and will always be problematic. They inflict violence
upon two languages." (translation from German)
-
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
next prev parent reply other threads:[~2007-04-29 16:02 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-28 22:05 [RFC] TileFS - a proposal for scalable integrity checking Matt Mackall
2007-04-29 12:21 ` Jörn Engel
2007-04-29 12:57 ` Matt Mackall
2007-04-29 15:47 ` Jörn Engel
2007-05-09 5:56 ` Valerie Henson
2007-05-09 10:12 ` Jörn Engel
2007-04-29 15:58 ` Jörn Engel [this message]
2007-04-29 16:24 ` Matt Mackall
2007-04-29 16:34 ` Andi Kleen
2007-04-29 16:05 ` Jörn Engel
2007-04-29 16:09 ` Matt Mackall
2007-04-29 23:23 ` Theodore Tso
2007-04-30 1:40 ` Matt Mackall
2007-04-30 17:26 ` Theodore Tso
2007-04-30 17:59 ` Matt Mackall
2007-05-02 13:18 ` Jörn Engel
2007-05-02 13:32 ` Jörn Engel
2007-05-02 15:37 ` Matt Mackall
2007-05-02 16:35 ` Jörn Engel
2007-05-09 7:56 ` Valerie Henson
2007-05-09 11:16 ` Nikita Danilov
2007-05-09 18:56 ` Valerie Henson
2007-05-09 19:19 ` Nikita Danilov
2007-05-09 17:06 ` Matt Mackall
2007-05-09 18:59 ` Valerie Henson
2007-05-09 19:51 ` Matt Mackall
2007-05-10 0:03 ` Jörn Engel
2007-05-11 9:46 ` Valerie Henson
2007-05-11 15:55 ` Matt Mackall
2007-05-09 19:01 ` Valerie Henson
2007-05-09 20:05 ` Matt Mackall
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=20070429155847.GC30608@lazybastard.org \
--to=joern@lazybastard.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mpm@selenic.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).