Hi,
On Mon, 2006-04-24 at 16:19 -0600, Andreas Dilger wrote:
> On Apr 24, 2006 14:53 +0100, Steven Whitehouse wrote:
> > On Sun, 2006-04-23 at 01:55 -0600, Andreas Dilger wrote:
> > > > +++ b/include/linux/iflags.h
> > > > @@ -0,0 +1,104 @@
> > > > +#define IFLAG_TOPDIR __IFL(TopDir) /* 0x00020000 */
> > > > +#define IFLAG_DIRECTIO __IFL(DirectIO) /* 0x00040000 */
> > > > +#define IFLAG_INHERITDIRECTIO __IFL(InheritDirectIO) /* 0x00080000 */
> > > > +#define IFLAG_INHERITJDATA __IFL(InheritJdata) /* 0x00100000 */
> > > > +#define IFLAG_RESERVED __IFL(Reserved) /* 0x80000000 */
> > >
> > > Actually, the 0x0080000 flag has been reserved by e2fsprogs for ext3
> > > extents for a while already. AFAICS, there are no other flags in the
> > > current e2fsprogs that aren't listed above.
> >
> > So if I call that one IFLAG_EXTENT, then I presume that will be ok?
> > What about the 0x00040000 flag? That would seem to be a gap in the
> > sequence (ignoring GFS flags for now), so should I leave that reserved
> > for use by ext2/3 as well?
>
> To be honest, I don't know if 0x40000 is used or not. It isn't in the
> e2fsprogs version of ext2_fs.h.
>
Hmmm... I think I might leave it "spare" all the same just in case
something else is using it. We can always fill it in later if thats not
the case.
> > > The other tidbit is that new ext2/ext3 files generally inherit the flags
> > > from their parent directory, so it isn't clear if there is really a need
> > > for a distinction between DIRECTIO and INHERIT_DIRECTIO, and similarly
> > > JDATA and INHERIT_JDATA? Generally, I'd think that JDATA isn't meaningful
> > > on directories (since they are metadata and journaled anyways), nor is
> > > DIRECTIO so their only meaning on a directory is "INHERIT for new files".
> >
> > Yes, that sounds like a good plan. The only downside (purely from a GFS2
> > point of view, it won't affect anybody else) means that its no longer a
> > 1:1 relationship between flags, so in order to do the conversion, I'd
> > have to use something a little more elaborate than the inline function I
> > added to the iflags.h header file,
>
> Hmm, maybe I don't understand the GFS2 issue then? Why not just use
> IFLAG_JDATA on the directory and remove the use of IFLAG_INHERITJDATA
> (equivalent) entirely from GFS2? Does the implementation depend on a
> distinction between these on a directory?
>
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
>
Its just a question of being compatible with GFS1 so far as the on disk
format goes. The gfs2_dinode structure is 100% backward compatible
(there are a couple of fields used in GFS1 no longer used in GFS2, but
they are otherwise identical) and this includes the flags. If I were
designing from scratch I'd certainly have merged the flags into one as
you suggest. Its not a big problem though - I just need to add a bit of
extra conversion code. Its better to do that than clutter the user
interface with redundant flags I think, especially when there are a
limited number,
Steve.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
