Ext3 users - Jan 2007 - CHANGE IN THE struct ext3_dir_entry_2 IS SUGGESTED

well a change in the struct ext3_dir_entry_2 like

 ++ change in the structure

 struct ext33_dir_entry_2 {

++           union {
                      __le32 inode;
++                     struct ext33_inode *emb_i;

++                    }  u_emb_i;

        __le16    rec_len;        /* Directory entry length */
        __u8    name_len;        /* Name length */
        __u8    file_type;
        char    name[EXT3_NAME_LEN];    /* File name */

       }*de;

initially the default access was through the *de which referenced only
de->inode but the change is as follows

well we have reflected  the changes in the ext3 filesystem source code using
the above structure (but only used the u_emb_i.inode)

we just wanted to know is ther any change to be done in EXT3_DIR_REC_LEN
macro

#define EXT3_DIR_PAD            4
#define EXT3_DIR_ROUND            (EXT3_DIR_PAD - 1)
#define EXT3_DIR_REC_LEN(name_len)     (((name_len)  + 8 + EXT3_DIR_ROUND) &
\
                     ~EXT3_DIR_ROUND)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20070131/6363c5f8/attachment.htm>

On Wed, Jan 31, 2007 at 12:00:36PM +0530, tushar wrote:
> well a change in the struct ext3_dir_entry_2 like
> 
> ++ change in the structure
> 
> struct ext33_dir_entry_2 {
> 
> ++           union {
>                      __le32 inode;
> ++                     struct ext33_inode *emb_i;
> 
> ++                    }  u_emb_i;
> 
>        __le16    rec_len;        /* Directory entry length */
>        __u8    name_len;        /* Name length */
>        __u8    file_type;
>        char    name[EXT3_NAME_LEN];    /* File name */
> 
>       }*de;
This change doesn't make any sense to me.  The ext3_dir_entry_2 data
structure reflects an on-disk layout.  As such putting pointers into
an on-disk data structure isn't particularly useful.  

If the goal is to make an incompatible change to the filesystem format
to store the inode embedded into the directory structure instead of in
the inode table, it's something that I've thought about, and in fact
there was a Usenix paper exploring this idea about ten years ago.  The
hard part with doing something like this managing hard links,
particularly when an inode is originally created in one directory,
hardlinked in another directory, and then the original directory entry
is removed.  There are ways of dealing it, but it's non-trivial.

In any case, an incompatible change like this is not something that
would be made to ext3.  It's something that potentially could be
considered for ext4, but as I said, there are a lot of issues that
would have to be considered and thought through first.  Probably
better to move that sort of discussing to the linux-ext4 mailing list
on vger.kernel.org.

Regards,

						- Ted