[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <20090820014058.GY5931@webber.adilger.int>
Date: Wed, 19 Aug 2009 19:40:58 -0600
From: Andreas Dilger <adilger@....com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: linux-ext4@...r.kernel.org, Pravin Shelar <Pravin.Shelar@....com>
Subject: Re: [RFC] new INCOMPAT flag for extended directory data
On May 05, 2009 14:25 -0600, Andreas Dilger wrote:
> we're looking to store some extended data in each directory entry
> for Lustre, to hold a 128-bit filesystem-unique file identifier
> in the dirent. If we ever wanted to look at 64-bit or larger
> inode numbers we would need to do the same.
>
> In order to detect the presence of this extra data in the dirent, we
> would want to use the high bits in d_type (say bits 0xf0). This part
> of d_type could be a flag for the presence of 4 different types of
> data (which limits the number of different kinds of data). The d_type
> would mask off the high bits in get_dtype() so as not to confuse filldir.
Ted,
could we at least reserve the INCOMPAT_DIRDATA flag to avoid conflicts:
#define EXT4_FEATURE_INCOMPAT_DIRDATA 0x1000
reserve the high 4 bits of d_type:
#define EXT4_DIRENT_LUFID 0x10 /* Lustre 128-bit unique file identifier */
0x20, 0x40, and 0x80 would be available for future expansion (e.g. high
32 bits of inode number). If needed, type 0x80 can be extended by adding
a 1-byte subtype after the length byte, though I doubt this would be needed.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists