On Nov 17, 2001 14:23 -0800, Mike Fedyk wrote:
> That's what I meant by "as long as the inode number is the same". Since it
> is a normal file, the only thing ext2resize might overlook would be the
> inode number for the jounal that's kept in the super block. If, in fact
> ext2resize does decide to change inode numbers for some reason. I don't
> know if it does.
ext2resize will only move inodes at the end of the fs, and only if you are
shrinking the fs. I suppose in some cases (creating a journal on an old
fs) there might be a journal not in the first group, but it is unlikely,
since ext2 will always allocate files in the same group as the parent
(the root inode), so it would always be in the first group, unless you
were out of inodes there (unlikely). With newer e2fsck's, it also moves
the journal to the reserved inode (#8) so it would remove that problem.
With online resizing (not that it works with ext3 yet, but) since you are
only ever growing the fs, you would also not renumber the inodes.
> Can ext2resize change the block size too? If the journal is larger than
> 100MB then it would need to be made smaller for 1k blocks 200MB for 2k
> blocks, and left at 400MB for 4k blocks.
No, that is a very difficult problem (especially growing the blocksize,
which is what most people would want to do), because none of the 1kB
blocks would be aligned properly. You would need to move basically all
of the data in the filesystem, at which point you are far better off to
create a new fs and copy over the data - faster and much less likely to
have any problems.
Cheers, Andreas
-- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 23 2001 - 21:00:16 EST