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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.