From: Kyle Moffett <mrmacman_g4@mac.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: John Richard Moser <nigelenki@comcast.net>, linux-kernel@vger.kernel.org
Subject: Re: soft update vs journaling?
Date: Mon, 23 Jan 2006 08:33:20 -0500 [thread overview]
Message-ID: <536E71BF-44FF-430C-8C19-F06526F0C78D@mac.com> (raw)
In-Reply-To: <20060123072447.GA8785@thunk.org>
On Jan 23, 2006, at 02:24, Theodore Ts'o wrote:
> Hot-shrinking a filesystem is certainly possible for any
> filesystem, but the problem is how many filesystem data structures
> you have to walk in order to find all the owner of all of the
> blocks that you have to relocate. That generally isn't a RAM
> overhead problem, but the fact that in general, most filesystems
> don't have an efficient way to answer the question, "who owns this
> arbitrary disk block?" Having extents means you have a slightly
> more efficient encoding system, but it still is the case that you
> have to check potentially every file in the filesystem to see if it
> is the owner of one of the disk blocks that needs to be moved when
> you are shrinking the filesystem.
The way that I'm considering implementing this is by intentionally
fragmenting the allocation bitmap, catalog file, etc, such that each
1/8 or so of the disk contains its own allocation bitmap describing
its contents, its own set of files or directories, etc. The
allocator would largely try to keep individual btree fragments
cohesive, such that one of the 1/8th divisions of the disk would only
have pertinent data for itself. The idea would be that when trying
to look up an allocation block, in the common case you need only
parse a much smaller subsection of the disk structures.
> And the only use for such a [reverse-mapping] data structure would
> be to make shrinking a filesystem more efficient.
Not entirely true. I _believe_ you could use such data structures to
make the allocation algorithm much more robust against fragmentation
if you record the right kind of information.
Cheers,
Kyle Moffett
--
If you don't believe that a case based on [nothing] could potentially
drag on in court for _years_, then you have no business playing with
the legal system at all.
-- Rob Landley
next prev parent reply other threads:[~2006-01-23 13:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-22 6:42 soft update vs journaling? John Richard Moser
2006-01-22 8:51 ` Jan Engelhardt
2006-01-22 18:40 ` John Richard Moser
2006-01-22 19:05 ` Adrian Bunk
2006-01-22 19:08 ` Arjan van de Ven
2006-01-22 19:25 ` Adrian Bunk
2006-01-24 2:33 ` Jörn Engel
2006-01-22 9:31 ` Theodore Ts'o
2006-01-22 18:54 ` John Richard Moser
2006-01-22 21:02 ` Theodore Ts'o
2006-01-22 22:44 ` Kyle Moffett
2006-01-23 7:24 ` Theodore Ts'o
2006-01-23 13:31 ` Mitchell Blank Jr
2006-01-23 13:33 ` Kyle Moffett [this message]
2006-01-23 13:52 ` Antonio Vargas
2006-01-23 16:48 ` Linux VFS architecture questions Kyle Moffett
2006-01-23 17:00 ` Pekka Enberg
2006-01-23 17:50 ` Kyle Moffett
2006-01-23 17:54 ` Randy.Dunlap
2006-01-23 20:48 ` soft update vs journaling? Folkert van Heusden
2006-01-23 1:02 ` John Richard Moser
2006-01-22 19:50 ` Diego Calleja
2006-01-22 20:39 ` Suleiman Souhlal
2006-01-22 20:50 ` Diego Calleja
2006-01-23 1:00 ` John Richard Moser
2006-01-23 1:09 ` Suleiman Souhlal
2006-01-23 2:09 ` John Richard Moser
2006-01-22 19:26 ` James Courtier-Dutton
2006-01-23 0:06 ` John Richard Moser
2006-01-23 5:32 ` Michael Loftis
2006-01-23 18:52 ` John Richard Moser
2006-01-23 19:32 ` Matthias Andree
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=536E71BF-44FF-430C-8C19-F06526F0C78D@mac.com \
--to=mrmacman_g4@mac.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nigelenki@comcast.net \
--cc=tytso@mit.edu \
/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).