bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Resizing ext3


From: Andrew Clausen
Subject: Re: Resizing ext3
Date: Mon, 16 Jun 2003 11:52:19 +0000
User-agent: Mutt/1.5.4i

On Sun, Jun 15, 2003 at 06:29:19PM -0700, Greg Roelofs wrote:
> Andrew Clausen wrote:
> 
> > On Wed, Jun 11, 2003 at 02:44:29PM -0700, Anand Panangadan wrote:
> >
> >> Can parted resize ext3 partitions (assuming that I am
> >> not changing the START position)? When I try to do
> >> this on an unmounted ext3 partition on Redhat 9
> >> (parted 1.6.3), I get "No implementation: this ext2
> >> filesystem has a rather strange layout!". But the GNU
> >> parted webpage indicates that ext3 resizing is
> >> possible.
> 
> > This is not an ext3-related problem.  It's probably due to some
> > raid stride option, which Parted can't cope with.  See the
> > mke2fs manpage... look for the -R option.
> 
> On the contrary, it _is_ an ext3-related problem.

I define ext3 as "ext2's journalling feature".  I think this is the
consensus definition.

Can Parted resize vanilla ext2 file systems created with e2fsprogs
nowadays?  (I haven't tried it!  Not enough time for a while now).  To
be frank, I think Parted's ext2 code should be retired, and it should
interface with e2fsprogs.  Just e2fsprogs isn't particularly easy to
interface with.

> Now, whether mke2fs -j internally triggers -R I leave to you folks;
> the point is that -j == ext3, and there is no support in Parted 1.6.5
> for doing much of anything with ext3 partitions created by newer versions
> of e2fsprogs.  That includes a simple partition move into a larger and
> contiguous empty space, something that should be trivial for Parted to
> manage (given that it knows everything about the existing partition's
> layout and size, and a byte-for-byte copy of the data into an identical
> partition freshly created by itself as part of the "move" command should
> not require any knowledge whatsoever of the internal filesystem).  The
> only way I could imagine the trivial case _not_ working is if the file-
> system somehow requires knowledge of its physical location on disk, but
> that seems fairly ridiculous, at least to someone who's never messed
> with low-level Linux filesystem and disk-partition code...

Well, a byte-for-byte copy would work, but it wouldn't utilize the
entire partition.  (It wouldn't "notice" the extra space at the end)
I guess it could be useful to have such a feature.

Cheers,
Andrew





reply via email to

[Prev in Thread] Current Thread [Next in Thread]