From: John Richard Moser <nigelenki@comcast.net>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: soft update vs journaling?
Date: Sun, 22 Jan 2006 20:02:29 -0500 [thread overview]
Message-ID: <43D42B25.3010706@comcast.net> (raw)
In-Reply-To: <20060122210238.GA28980@thunk.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Theodore Ts'o wrote:
> On Sun, Jan 22, 2006 at 01:54:23PM -0500, John Richard Moser wrote:
>
>>>Whenever you want to extend a filesystem to add some new feature, such
>>>as online resizing, for example, it's not enough to just add that
>>
>>Online resizing is ever safe? I mean, with on-disk filesystem layout
>>support I could somewhat believe it for growing; for shrinking you'd
>>need a way to move files around without damaging them (possible). I
>>guess it would be.
>>
>>So how does this work? Move files -> alter file system superblocks?
>
>
> The online resizing support in ext3 only grows the filesystems; it
> doesn't shrink it. What is currently supported in 2.6 requires you to
> reserve space in advance. There is also a slight modification to the
> ext2/3 filesystem format which is only supported by Linux 2.6 which
> allows you to grow the filesystem without needing to move filesystem
> data structures around; the kernel patches for actualling doing this
> new style of online resizing aren't yet in mainline yet, although they
> have been posted to ext2-devel for evaluation.
>
>
>>A passive-active approach could passively generate a list of inodes from
>>dentries as they're accessed; and actively walk the directory tree when
>>the disk is idle. Then a quick allocation check between inodes and
>>whatever allocation lists or trees there are could be done.
>
>
> That doesn't really help, because in order to release the unused disk
> blocks, you have to walk every single inode and keep track of the
> block allocation bitmaps for the entire filesystem. If you have a
> really big filesystem, it may require hundreds of megabytes of
> non-swappable kernel memory. And if you try to do this in userspace,
> it becomes an unholy mess trying to keep the userspace and in-kernel
> mounted filesystem data structures in sync.
>
Yeah I figured that you couldn't take action until everything was seen;
I can see how you could have problems with all that kernel memory ;)
FUSE driver, anyone? :>
(I've actually looked into FUSE for the rootfs, via loading a fuser
driver from an init.d and then replacing bash with init on the rootfs;
haven't found an ext2 or xfs fuse driver to test with)
> - Ted
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD1CskhDd4aOud5P8RArmJAJ9mgLjkxUcg5GW1o4q88Cb6ESmdCACZAS00
M1R+7biZpmOCCCBkEXVQL7w=
=060w
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2006-01-23 1:03 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
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 [this message]
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=43D42B25.3010706@comcast.net \
--to=nigelenki@comcast.net \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.