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
_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
