Ext3 users - May 2006 - Fedora Core 4 and FC5's NEW EXT3 file system: "Reserved GDT blocks" ???

Hi,

 I've installed a few Fedora Core 4 and Fedora Core 5
recently, and found that the new ext3 file systems
created with new mkfs.ext3(1.38+) has one more field
than EXT3 created with old mkfs.ext3(1.34-), even the
latter's dir_index feature was turned on and file
systems were upgraded with "e2fsck -y -f -D" command.

 I have three questions thereafter:

1) what does the "Reserved GDT blocks" mean? and what
are its functions and purposes?

2) for file systems created with older versions of
mkfs.ext3(v1.34-) on FC1, how to upgrade it to the
newest version? 

I manually turned on dir_index(which is by default OFF
for 1.34-, but by default ON on 1.38+) with command
"tune2fs -O dir_index", then run command "e2fsck -y -f
-D" to upgrade it (e2fsck is 1.38+).

If the above upgrade way is the "official" way? If
not, then what is the prefered way to upgrade old ext3
file system to be used on FC4/FC5?

3) are there any other difference besides "Reserved
GDT blocks" between newly created ext3 file systems
and upgraded ones by e2fsck?

Please help. 

Thanks a lot.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

On Sun, May 07, 2006 at 01:25:07AM -0700, Robinson Tiemuqinke
wrote:
> 
>  I've installed a few Fedora Core 4 and Fedora Core 5
> recently, and found that the new ext3 file systems
> created with new mkfs.ext3(1.38+) has one more field
> than EXT3 created with old mkfs.ext3(1.34-), even the
> latter's dir_index feature was turned on and file
> systems were upgraded with "e2fsck -y -f -D" command.
> 
>  I have three questions thereafter:
> 
> 1) what does the "Reserved GDT blocks" mean? and what
> are its functions and purposes?
It means that blocks have been reserved in order to allow on-line
resizing.  The filesystem will also have "resize_inode" in the
filesystem features line reported by dumpe2fs.  This is most useful if
the filesystem has been created on a Logical Volume managed by an LVM
system so that when the LV is expanded, the filesystem can take
advantage of the new disk space without needing to unmount the
filesystem first.

Filesystems that don't have this set can of course still be resized
off-line using resize2fs.
> 2) for file systems created with older versions of
> mkfs.ext3(v1.34-) on FC1, how to upgrade it to the
> newest version? 
There isn't a way to do this that is supported by Fedora.  You can use
the ext2prepare tool that is part of ext2resize package on sf.net, but
Red Hat hasn't been willing to support that package, and I haven't
been willing to accept that code into the mainline e2fsprogs for
code-quality reasons.  (Doing a complete rewrite of the program from
the ground up is on my todo list, but to be honest other things are
higher priority.)
> I manually turned on dir_index(which is by default OFF
> for 1.34-, but by default ON on 1.38+) with command
> "tune2fs -O dir_index", then run command "e2fsck -y -f
> -D" to upgrade it (e2fsck is 1.38+).
> 
> If the above upgrade way is the "official" way? If
> not, then what is the prefered way to upgrade old ext3
> file system to be used on FC4/FC5?
If you enable the dir_index field, when any directories grow beyond a
single disk block, they are automatically become indexed using a hash
tree.  (There's no point using a hash tree if the directory is only a
single block.)  You can actually do this on a mounted filesystem, and
it will take effect immediately.

The "e2fsck -fD" command will cause e2fsck to rebuild and reindex any
directories which are larger than a single disk block.  So this will
give you the benefit of directory indexing for all large directories
on the filesystem. 

The directory indexing feature is completely orthogonal to the
resize_inode feature (which allows on-line resizing).
> 3) are there any other difference besides "Reserved
> GDT blocks" between newly created ext3 file systems
> and upgraded ones by e2fsck?
Yes, see above.  But unless your filesystem is on an LVM-managed LV,
it probably doesn't matter so much that you can't on-line grow the
filesystem.

Hope this helps,

						- Ted