On 2012-02-27, at 12:09 PM, Ted Ts'o wrote:

On Sun, Feb 26, 2012 at 08:30:34PM -0700, Andreas Dilger wrote:

quoted

quoted

I'd suggest folding this in with the following patch (67/73).  It's
not clear from this patch why renaming ext2_add_link to
ext2_add_entry() makes sense and then adding a new ext2_add_link()
which calls ext_add_entry().   It doesn't seem to clarify much....

Also, why is this being done in ext2, when it should only be done in ext4?

I believe Val used ext2 as a proof-of-concept, because the codebase
was stable (and Union Mounts has been in the oven a loooong time, so
that was probably a good choice).  I agree that if union mounts is
finally going to make it upstream, this would be a good time to
support implemented for ext4, and to get the support into e2fsprogs.

BTW, one thing that I think would be a good thing to do while we're
making this change is to mask off the low 4 bits when looking at the
filetype field so eventually we can use the high 4 bits for some
future extension.

Umm, we already DO use the high 4 bits for a future extension in the
EXT4_FEATURE_INCOMPAT_DIRDATA feature.  The bare minimum for this is
extracted from a larger patch that allows storing extra data in the
dirent.  We use it to store a filesystem-wide 128-bit identifier into
the dirent, and it could also be used to store the high 32 bits of the
inode number in a compatible way.

I haven't pushed this upstream as I don't think anyone else is interested
in this yet, but masking off the file type is definitely simple and could
be accepted upstream.

Index: linux-stage/fs/ext4/ext4.h
===================================================================

--- linux-stage.orig/fs/ext4/ext4.h
+++ linux-stage/fs/ext4/ext4.h

@@ -1262,6 +1265,24 @@ struct ext4_dir_entry_2 {
 #define EXT4_FT_SYMLINK		7

 #define EXT4_FT_MAX		8
+#define EXT4_FT_MASK		0xf
+
+#if EXT4_FT_MAX > EXT4_FT_MASK
+#error "conflicting EXT4_FT_MAX and EXT4_FT_MASK"
+#endif
+
+/*
+ * d_type has 4 unused bits, so it can hold four types data. these different
+ * type of data (e.g. lustre file ID, high 32 bits of 64-bit inode number)
+ * can be stored, in flag order, after file-name in ext4 dirent.
+*/
+/*
+ * This flag is added to d_type if ext4 dirent has extra data after filename.
+ * This data length is variable and length is stored in first byte of data.
+ * Data starts after filename NUL byte. This is used by Lustre FS.
+  */
+#define EXT4_DIRENT_LUFID		0x10

 /*
  * EXT4_DIR_PAD defines the directory entries boundaries

Index: linux-stage/fs/ext4/dir.c
===================================================================

--- linux-stage.orig/fs/ext4/dir.c
+++ linux-stage/fs/ext4/dir.c

@@ -53,11 +53,14 @@ const struct file_operations ext4_dir_op
 
 static unsigned char get_dtype(struct super_block *sb, int filetype)
 {
+	int fl_index = filetype & EXT4_FT_MASK;
+
 	if (!EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_FILETYPE) ||
-	    (filetype >= EXT4_FT_MAX))
+	    (fl_index >= EXT4_FT_MAX))
 		return DT_UNKNOWN;

-	return (ext4_filetype_table[filetype]);
+	return ext4_filetype_table[fl_index]);
+
 }

Cheers, Andreas