Re: e2fsck and large inodes

On Oct 15, 2003  11:37 -0400, Theodore Ts'o wrote:
> On Wed, Oct 15, 2003 at 06:23:06PM +0400, Alex Tomas wrote:
> > Let me ask you for advice. I'd like to implement e2fsck support for
> > EA-in-inode feature. Unfortunately, I observed large inodes aren't
> > supported well in e2fsck. I mean that most of code work using struct
> > ext2_inode, thus ignoring additional space. What's the best way to
> > implement such a support? couple ideas come in my mind:
> > 
> > 1) to redefine struct ext2_inode to cover max possible inodes
> >    (I really dislike this ...)
> > 
> > 2) to go through the code and allocate struct ext2_inode + remains
> >    from the heap
> 
> What I always had in mind is that we would expand the ext2 inode in
> two ways, both by expanding the number of fixed fields (with a field
> in the superblock to indicate how much of the inode is to be used for
> fixed fields), as well as including space for type-length value (TLV)
> fields (which would be used for the EA in inode feature).  This is
> because certain expanded features, such as subsecond resolution for
> the timestamps, really make sense to be done by expanding the inode
> fixed fields, rather than forcing the kernel to parse through all of
> the TLV fields to find the expanded timestamp EA.  

Just FYI, this is exactly how it is implemented.  The current usage of
the new inode space looks like:

        } osd2;                         /* OS dependent 2 */
+       __u16   i_extra_isize;
+       __u16   i_pad1;
 };

So just a 16-bit value which indicates the amount of extra space used by
the fixed fields (currently 4 bytes for an empty size).  We need to store
this value per inode because the number of fixed fields can grow over time
and the current number of fields supported by the ext3 code may be more
than were written into the inode.

The EA magic follows i_pad1 immediately and the rest of the inode is used
for EA data in the same format as the current EA data.

We had a patch for some time which implemented i_uctime, i_umtime
(we probably don't really need i_uatime or i_udtime) but we didn't get
any feedback on what the structue of those fields should be so we left
them out for now.  I prefer a format like i_uctime & 0xfffff == useconds
and in addition (i_uctime & 0xfff00000) >> 20 == high 12 bits of seconds
field for > 32-bit timestamps.  We could shift these around to increase
the resolution and decrease the range of the timestamps.  If we had 4 bits
of high times gives us 1088 years from 1970, or 2177 years if we take it as
unsigned.  28 bits of subsecond time gives us 4ns resolution if we are
storing the decimal nsecond/4 value in the low 28 bits (we have a max
decimal value of 250,000,000 and a range of 268,435,456).

> I imagine that for most users of libext2fs, including e2fsck, they
> would only need the fixed ext2 inode fields.  So it would make sense
> for struct ext2_inode to contain the fixed fields and an optional
> pointer to the remaining bits of the inode.  It might or might not
> make sense to optionally decide whether or not to allocate/read the
> TLV portion of the inode.

We will already read the EA part of the inode from disk while reading the
inode table (it will always be in the same block as the inode), so it
makes sense to stick it into a struct hanging off the inode at that time
(if it exists) instead of throwing away that data and incurring basically
full-itable reads again while reading the inline EA data later on.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php