xfs
[Top] [All Lists]

Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-

To: Felix Blyakher <felixb@xxxxxxx>
Subject: Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20838-g5123bc3
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 9 Apr 2009 13:05:05 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <730FBF20-6F2C-42FA-A19F-67F6C6279445@xxxxxxx>
References: <200903310323.n2V3NoRK232157@xxxxxxxxxxx> <20090331071124.GA12889@xxxxxxxxxxxxx> <730FBF20-6F2C-42FA-A19F-67F6C6279445@xxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Mar 31, 2009 at 07:59:19AM -0500, Felix Blyakher wrote:
> It does, though it's not as severe as other disk format changes.
> I don't have a final solution yet, but since it's already escaped
> in public, I may as well show my current thinking, and invite
> comments.
> So, the older kernels would be able to mount and work with the
> new filesystem, with exception of seeing only first 25 ACL
> entries. The user may still would like to mount it as such
> confirming that he aware of consequences. This feature validation
> would not follow the current scheme of black and white. With
> the presence of the force_mount (new) option, we emit a warning
> and allow to mount.
> Comments?

We do need a on-disk feature flag, yes.  And we can have a large-acl or
similar mount option to automatically set that flag if we create a
larger than existing number of acls. 

But if we are going to change this just upping the number of entires to
another static value seems rather dumb, we should better make it
completely dynamic.

The only way why it's static is to be able to allocate the space for
the acl upfront before the attr_get call.  We can just try the 25 entry
one first and if xfs_attr_get tells us it's too small try again with the
correct value.  

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20838-g5123bc3, Christoph Hellwig <=