lkml.org 
[lkml]   [2012]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [PATCH 66/73] ext2: Split ext2_add_entry() from ext2_add_link() [ver #2]
From
Date
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:
>>> 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







\
 
 \ /
  Last update: 2012-02-27 21:49    [W:0.062 / U:34.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site