From: David Chinner <dgc@sgi.com>
To: Timothy Shimmin <tes@sgi.com>
Cc: Jan Engelhardt <jengelh@computergmbh.de>,
David Chinner <dgc@sgi.com>,
xfs@oss.sgi.com
Subject: Re: ACL limit
Date: Mon, 3 Dec 2007 11:23:49 +1100 [thread overview]
Message-ID: <20071203002349.GV119954183@sgi.com> (raw)
In-Reply-To: <475343FB.3060902@sgi.com>
On Mon, Dec 03, 2007 at 10:47:07AM +1100, Timothy Shimmin wrote:
> David Chinner wrote:
> >On Fri, Nov 30, 2007 at 07:07:26PM +0100, Jan Engelhardt wrote:
> >>Hi,
> >>
> >>
> >>is there any way to raise the number of ACLs that can be stored? The
> >>current limit of 25 is quite tight, where ext3 allows 124 and jfs 8192.
> >>Would increasing XFS_ACL_MAX_ENTRIES work (yes, using potentially more
> >>memory), i.e. not interfering with the on-disk format?
> >
> >It would be an on disk format change - older kernels would error out
> >(-EINVAL) on > 25 ACLs and not check any of them. Hence we'd
> >probably need a superblock feature bit to indicate that >25 ACEs are
> >supported in a given ACL.
> >
> >But we can work around that (superblock feature bit) and should
> >be able to extend this out to ~8190 entries. We're doing an ACL
> >rework ATM, so > 25 entry support should fall out of that....
>
> Yeah, it's just an array of entries in an EA value.
> The EA value is limited to 64K so it's a question of how
> many entries you can fit into that.
> (64K - 4)/12 = 5461
Confused - I thought the ACE was 8 bytes:
struct posix_acl_entry {
short e_tag;
unsigned short e_perm;
unsigned int e_id;
};
Also, JFS only allows 64k for the xattr as well (jfs_xattr.h):
/* Macros for defining maxiumum number of bytes supported for EAs */
#define MAXEASIZE 65535
#define MAXEALISTSIZE MAXEASIZE
And (64k - 4)/8 = 8191 which is what JFS supports.
Oh:
typedef __uint16_t xfs_acl_perm_t;
typedef __int32_t xfs_acl_type_t;
typedef __int32_t xfs_acl_tag_t;
typedef __int32_t xfs_acl_id_t;
#define XFS_ACL_MAX_ENTRIES 25
#define XFS_ACL_NOT_PRESENT (-1)
typedef struct xfs_acl_entry {
xfs_acl_tag_t ae_tag;
xfs_acl_id_t ae_id;
xfs_acl_perm_t ae_perm;
} xfs_acl_entry_t;
typedef struct xfs_acl {
__int32_t acl_cnt;
xfs_acl_entry_t acl_entry[XFS_ACL_MAX_ENTRIES];
} xfs_acl_t;
An *XFS* ACE is 12 bytes and hence can't be passed directly to the
generic code. Tim - are we adding a translation layer or storing
the generic posix acl format on disk?
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
next prev parent reply other threads:[~2007-12-03 0:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-30 18:07 ACL limit Jan Engelhardt
2007-12-02 22:31 ` David Chinner
2007-12-02 23:47 ` Timothy Shimmin
2007-12-03 0:12 ` Jan Engelhardt
2007-12-03 0:23 ` David Chinner [this message]
2007-12-03 0:34 ` Timothy Shimmin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071203002349.GV119954183@sgi.com \
--to=dgc@sgi.com \
--cc=jengelh@computergmbh.de \
--cc=tes@sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox