Ted,
in addition to the data-in-dirent INCOMPAT flag Rahul sent the patches
for last week, I would like to ensure that we also have the INCOMPAT
flag for large EA-in-inode flag reserved. This patch is going into
testing at one of our large customers, and I want to make sure that
we don't accidentally get a conflicting INCOMPAT flag assignment.
#define EXT4_FEATURE_INCOMPAT_EA_INODE 0x0400
#define EXT4_FEATURE_INCOMPAT_DIRDATA 0x1000
#define EXT4_EA_INODE_FL 0x00200000 /* Inode used for large EA */
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
On 2009-09-06, at 03:25, Andreas Dilger wrote:
> in addition to the data-in-dirent INCOMPAT flag Rahul sent the patches
> for last week, I would like to ensure that we also have the INCOMPAT
> flag for large EA-in-inode flag reserved. This patch is going into
> testing at one of our large customers, and I want to make sure that
> we don't accidentally get a conflicting INCOMPAT flag assignment.
>
> #define EXT4_FEATURE_INCOMPAT_EA_INODE 0x0400
> #define EXT4_FEATURE_INCOMPAT_DIRDATA 0x1000
>
> #define EXT4_EA_INODE_FL 0x00200000 /* Inode uses large EA */
Hi Ted,
I noticed Aneesh proposing to use the 0x0400 INCOMPAT flag for the
NFSv4 ACL support, but this conflicts with the large EA feature we had
previously discussed. We now have a couple of customers using the
large EA feature at this point, and I wouldn't want to break their
filesystem as a result of an avoidable conflict.
I'll attach patches for this, which will hopefully make it easier, and
the patch tracking tool will keep this visible.
Aneesh, maybe you can use 0x0800 for the INCOMPAT_RICHACL?
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
Attached is a patch to reserve the EA inode feature flag.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
Attached is a patch to reserve the data-in-dirent feature flag.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
On Mon, Nov 30, 2009 at 12:15:11PM -0700, Andreas Dilger wrote:
> On 2009-09-06, at 03:25, Andreas Dilger wrote:
> >in addition to the data-in-dirent INCOMPAT flag Rahul sent the patches
> >for last week, I would like to ensure that we also have the INCOMPAT
> >flag for large EA-in-inode flag reserved. This patch is going into
> >testing at one of our large customers, and I want to make sure that
> >we don't accidentally get a conflicting INCOMPAT flag assignment.
> >
> >#define EXT4_FEATURE_INCOMPAT_EA_INODE 0x0400
> >#define EXT4_FEATURE_INCOMPAT_DIRDATA 0x1000
> >
> >#define EXT4_EA_INODE_FL 0x00200000 /* Inode uses large EA */
>
>
> Hi Ted,
> I noticed Aneesh proposing to use the 0x0400 INCOMPAT flag for the
> NFSv4 ACL support, but this conflicts with the large EA feature we
> had previously discussed. We now have a couple of customers using
> the large EA feature at this point, and I wouldn't want to break
> their filesystem as a result of an avoidable conflict.
>
> I'll attach patches for this, which will hopefully make it easier,
> and the patch tracking tool will keep this visible.
>
> Aneesh, maybe you can use 0x0800 for the INCOMPAT_RICHACL?
>
>
I have updated richacl patches to use 0x0800.
-aneesh
On Sun, Sep 06, 2009 at 11:25:46AM +0200, Andreas Dilger wrote:
> Ted,
> in addition to the data-in-dirent INCOMPAT flag Rahul sent the patches
> for last week, I would like to ensure that we also have the INCOMPAT
> flag for large EA-in-inode flag reserved. This patch is going into
> testing at one of our large customers, and I want to make sure that
> we don't accidentally get a conflicting INCOMPAT flag assignment.
>
> #define EXT4_FEATURE_INCOMPAT_EA_INODE 0x0400
> #define EXT4_FEATURE_INCOMPAT_DIRDATA 0x1000
>
> #define EXT4_EA_INODE_FL 0x00200000 /* Inode used for large EA */
>
Reserving... but stupid question, do you know if anyone is currently
using the inode flag 0x00100000? I want to make sure that's properly
documented and reserved.
Thanks,
- Ted
On 2010-01-24, at 12:48, [email protected] wrote:
> On Sun, Sep 06, 2009 at 11:25:46AM +0200, Andreas Dilger wrote:
>> in addition to the data-in-dirent INCOMPAT flag Rahul sent the
>> patches
>> for last week, I would like to ensure that we also have the INCOMPAT
>> flag for large EA-in-inode flag reserved. This patch is going into
>> testing at one of our large customers, and I want to make sure that
>> we don't accidentally get a conflicting INCOMPAT flag assignment.
>>
>> #define EXT4_FEATURE_INCOMPAT_EA_INODE 0x0400
>> #define EXT4_FEATURE_INCOMPAT_DIRDATA 0x1000
>>
>> #define EXT4_EA_INODE_FL 0x00200000 /* Inode used for large EA */
>
> Reserving... but stupid question, do you know if anyone is currently
> using the inode flag 0x00100000? I want to make sure that's properly
> documented and reserved.
It doesn't seem that ext2/3/4 are using the 0x00100000 value itself,
but it seems the VFS is using this value for FS_DIRECTIO_FL. Should
we reserve this in the ext4 flags also, to avoid collisions? I'm not
sure what that flag is for, possibly to force all IO to the file to be
uncached?
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
On Sun, Jan 24, 2010 at 11:18:47PM -0700, Andreas Dilger wrote:
>
> It doesn't seem that ext2/3/4 are using the 0x00100000 value itself,
> but it seems the VFS is using this value for FS_DIRECTIO_FL. Should
> we reserve this in the ext4 flags also, to avoid collisions? I'm
> not sure what that flag is for, possibly to force all IO to the file
> to be uncached?
Hmm, absolutely nothing seems to use FS_DIRECTIO_FL; it looks like it
was introduced by GFS2 in commit 128e5eba in 2006 and then dropped in
commit c9f6a6bb in 2008, but we never killed the FS_DIRECTIO_FL flag
itself in include/linux/fs.h.
The summary line for c9f6a6bb is a bit amusing:
[GFS2] Remove support for unused and pointless flag
Heh.
Sounds like we should just kill it. Any objections?
- Ted
Hi,
On Mon, 2010-01-25 at 03:06 -0500, [email protected] wrote:
> On Sun, Jan 24, 2010 at 11:18:47PM -0700, Andreas Dilger wrote:
> >
> > It doesn't seem that ext2/3/4 are using the 0x00100000 value itself,
> > but it seems the VFS is using this value for FS_DIRECTIO_FL. Should
> > we reserve this in the ext4 flags also, to avoid collisions? I'm
> > not sure what that flag is for, possibly to force all IO to the file
> > to be uncached?
>
> Hmm, absolutely nothing seems to use FS_DIRECTIO_FL; it looks like it
> was introduced by GFS2 in commit 128e5eba in 2006 and then dropped in
> commit c9f6a6bb in 2008, but we never killed the FS_DIRECTIO_FL flag
> itself in include/linux/fs.h.
>
> The summary line for c9f6a6bb is a bit amusing:
>
> [GFS2] Remove support for unused and pointless flag
>
> Heh.
>
> Sounds like we should just kill it. Any objections?
>
> - Ted
No. Sounds good to me. It was never used with GFS2 and it a left-over
from GFS1 which had a flag allowing all "normal" I/O to be turned into
O_DIRECT I/O depending on an inode flag. The idea failed due to
alignment restrictions of course and nobody actually used it,
Steve.
On Mon, Nov 30, 2009 at 12:31:40PM -0700, Andreas Dilger wrote:
> Attached is a patch to reserve the EA inode feature flag.
I had reserved this in ext4.h in the kernel, this is just a note to
say that I've checked in this change into e2fsprogs as well.
- Ted
On Mon, Nov 30, 2009 at 02:16:48PM -0700, Andreas Dilger wrote:
> Attached is a patch to reserve the data-in-dirent feature flag.
I had reserved this in ext4.h in the kernel, this is just a note to
say that I've checked in this change into e2fsprogs as well.
- Ted