bug-parted
[Top][All Lists]
Advanced

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

Re: strange ext2 layout with parted


From: Andrew Clausen
Subject: Re: strange ext2 layout with parted
Date: Tue, 28 Nov 2000 17:05:14 +1100

Andreas Dilger wrote:
> > Even when I try  to do a check on this partition it says the same.
> > I tried it then on all linux partitions, and all gave the same error.
> 
> Looking at the output from dumpe2fs, it is clear what the "problem" is.
> For the first few groups, you have block and inode bitmaps AFTER the
> inode table, but later groups have these bitmaps BEFORE the inode table.
> 
> To get a filesystem like this, you probably created the filesystem
> with the RAID stride option (which puts the bitmaps after the inode table),
> and then did a resize.  After the first resize (with older versions of
> ext2resize or parted) the bitmaps would be put in their default location
> before the inode table.
> 
> While this is perfectly legal for ext2, older versions of ext2resize
> (which is what parted is using) did not understand this layout of ext2.
> It required that you have the bitmaps in the same location in all of
> the groups, because it is easier to handle this case, and most filesystems
> are formatted that way.

Yep.  I intend to add resize-the-start support to Parted, and it would
make sense to do these together.  (Resize-the-start means that we
have to duplicate all metadata, like inode tables, etc., because
all blocks and inodes need to be renumbered...)

BTW, I think it makes no sense to have ext2resize and Parted separate.
Stuff ext2resize has on it's TODO list is done in Parted, and vice
versa.  Parted and ext2resize are now quite different (I've added
lots of error handling, added big-endian support, so the code, but
not the structure is quite different, in terms of the size of a
diff)

I do intend to do resize-the-start, soonish.

Andrew Clausen



reply via email to

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