From: Mark Tinguely <tinguely@sgi.com>
To: xfs@oss.sgi.com
Subject: Re: [PATCH 4/4] xfs: increase number of ACL entries for V5 superblocks
Date: Wed, 05 Jun 2013 08:38:19 -0500 [thread overview]
Message-ID: <51AF3F4B.2090300@sgi.com> (raw)
In-Reply-To: <51AF3C69.2040903@sgi.com>
On 06/05/13 08:26, Mark Tinguely wrote:
> On 06/04/13 21:09, Dave Chinner wrote:
>> From: Dave Chinner<dchinner@redhat.com>
>>
>> The limit of 25 ACL entries is arbitrary, but baked into the on-disk
>> format. For version 5 superblocks, increase it to the maximum nuber
>> of ACLs that can fit into a single xattr.
>>
>> Signed-off-by: Dave Chinner<dchinner@redhat.com>
>> Reviewed-by: Brian Foster<bfoster@redhat.com>
>> ---
>
>> /* On-disk XFS access control list structure */
>> +struct xfs_acl_entry {
>> + __be32 ae_tag;
>> + __be32 ae_id;
>> + __be16 ae_perm;
>> + __be16 ae_pad; /* fill the implicit hole in the structure */
>> +};
>> +
>> struct xfs_acl {
>> - __be32 acl_cnt;
>> - struct xfs_acl_entry {
>> - __be32 ae_tag;
>> - __be32 ae_id;
>> - __be16 ae_perm;
>> - } acl_entry[XFS_ACL_MAX_ENTRIES];
>> + __be32 acl_cnt;
>> + struct xfs_acl_entry acl_entry[0];
>> };
>>
>> +/*
>> + * The number of ACL entries allowed is defined by the on-disk format.
>> + * For v4 superblocks, that is limited to 25 entries. For v5
>> superblocks, it is
>> + * limited only by the maximum size of the xattr that stores the
>> information.
>> + */
>> +#define XFS_ACL_MAX_ENTRIES(mp) \
>> + (xfs_sb_version_hascrc(&mp->m_sb) \
>> + ? (XATTR_SIZE_MAX - sizeof(struct xfs_acl)) / \
>> + sizeof(struct xfs_acl_entry) \
>> + : 25)
>> +
>> +#define XFS_ACL_MAX_SIZE(mp) \
>> + (sizeof(struct xfs_acl) + \
>> + sizeof(struct xfs_acl_entry) * XFS_ACL_MAX_ENTRIES((mp)))
>> +
>> /* On-disk XFS extended attribute names */
>> #define SGI_ACL_FILE (unsigned char *)"SGI_ACL_FILE"
>> #define SGI_ACL_DEFAULT (unsigned char *)"SGI_ACL_DEFAULT"
>
> I thought you would leave the XFS_ACL_MAX_ENTRIES(mp) as:
>
...
never mind, now I get it "struct xfs_acl_entry acl_entry[0]" reserves
no space.
Reviewed-by: Mark Tinguely <tinuguely@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-06-05 13:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-05 2:09 [PATCH 0/4] xfs: outstanding fixes for 3.10 Dave Chinner
2013-06-05 2:09 ` [PATCH 1/4] xfs: fix log recovery transaction item reordering Dave Chinner
2013-06-05 13:13 ` Mark Tinguely
2013-06-05 2:09 ` [PATCH 2/4] xfs: inode unlinked list needs to recalculate the inode CRC Dave Chinner
2013-06-05 14:43 ` Mark Tinguely
2013-06-05 2:09 ` [PATCH 3/4] xfs: disable noattr2/attr2 mount options for CRC enabled filesystems Dave Chinner
2013-06-05 2:09 ` [PATCH 4/4] xfs: increase number of ACL entries for V5 superblocks Dave Chinner
2013-06-05 13:26 ` Mark Tinguely
2013-06-05 13:38 ` Mark Tinguely [this message]
2013-06-05 16:44 ` [PATCH 0/4] xfs: outstanding fixes for 3.10 Ben Myers
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=51AF3F4B.2090300@sgi.com \
--to=tinguely@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.