public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: John Richard Moser <nigelenki@comcast.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: soft update vs journaling?
Date: Sun, 22 Jan 2006 16:02:38 -0500	[thread overview]
Message-ID: <20060122210238.GA28980@thunk.org> (raw)
In-Reply-To: <43D3D4DF.2000503@comcast.net>

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.

						- Ted

  reply	other threads:[~2006-01-22 21: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 [this message]
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
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=20060122210238.GA28980@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nigelenki@comcast.net \
    /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