From: Michael Loftis <mloftis@wgops.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM onFly features
Date: Sat, 10 Dec 2005 13:14:54 -0700 [thread overview]
Message-ID: <A8AB02E392149E55AC45BF7A@dhcp-2-206.wgops.com> (raw)
In-Reply-To: <20051210200646.GF3103@mjk.myfqdn.de>
--On December 10, 2005 9:06:46 PM +0100 Marc-Jano Knopp
<pub_ml_lvm@marc-jano.de> wrote:
> On Sat, 10 Dec 2005 at 13:03 (-0700), Michael Loftis wrote:
>> --On December 10, 2005 8:48:27 PM +0100 Marc-Jano Knopp
>> <pub_ml_lvm@marc-jano.de> wrote:
>> > On Sat, 10 Dec 2005 at 14:38 (-0500), Mag Gam wrote:
>> >> any news about hot(no unmount, no fsck, no fs resize) ext2/ext3
>> >> filesystem increase?
>> >
>> > And when will online-*shrinking* of ext3 appear?
>>
>> These are not LVM features. These are filesystem features. Better to
>> ask on lkml, or the maintainers directly.
>
> D'oh! Sorry for that, I was misguided by the previous post!
Not a problem, a lot of people don't see the delineation right off.
Filesystems like VXVFS (Veritas) in their commercial implementations are
really LVM+Filesystem in one. Not sure what the linux port is looking like
these days though.
ReiserFS has hot expansion capabilities, but no (yet?) hot shrinking
capabilities. One of the reasons it has these features and ext2/3 does not
is because ext2/3 are very old filesystems designed on a different
mentality of a static filesystem. On-line expansion of ext2 based
filesystems is an extremely complicated venture, it might honestly even be
impossible.
ReiserFS has the advantage here because it doesn't necessarily pre-write
out a lot of filesystem meta-information (superblocks, inodes, bitmaps,
etc), instead these structures are entirely dynamic to begin with, so
enlarging them at runtime is trivial, requires a very short lock and a
change to a few numbers. Ext2 resizing requires actually rewriting a lot
of filesystem metadata.
next prev parent reply other threads:[~2005-12-10 20:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-10 19:38 [linux-lvm] LVM onFly features Mag Gam
2005-12-10 19:48 ` Marc-Jano Knopp
2005-12-10 20:03 ` Michael Loftis
2005-12-10 20:06 ` Marc-Jano Knopp
2005-12-10 20:14 ` Michael Loftis [this message]
2005-12-10 20:22 ` Marc-Jano Knopp
2005-12-10 22:10 ` Michael Loftis
2005-12-10 22:31 ` Marc-Jano Knopp
2005-12-10 22:44 ` Michael Loftis
2005-12-10 22:51 ` Michael Loftis
2005-12-10 23:03 ` Marc-Jano Knopp
2005-12-11 3:38 ` Mag Gam
2005-12-11 7:43 ` Michael Loftis
2005-12-11 14:08 ` Fredrik Tolf
2005-12-11 15:32 ` Mag Gam
2005-12-15 20:44 ` David Johnston
2005-12-18 0:27 ` Mag Gam
2005-12-11 22:15 ` Nathan Scott
2005-12-12 1:14 ` Michael Loftis
2005-12-12 2:28 ` Nathan Scott
2005-12-10 20:47 ` Graham Wood
2005-12-13 16:56 ` Stephen C. Tweedie
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=A8AB02E392149E55AC45BF7A@dhcp-2-206.wgops.com \
--to=mloftis@wgops.com \
--cc=linux-lvm@redhat.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).