Hi Linda,
Linda A. Walsh wrote:
> my man page says extended xfs attributes can have 256-byte names
> with up to 64K of data.
>
> Is there a limit on the number of extended attributes max data size or
> name size?
>
> I.e. could I have 1000 attributes with 64K of data each?
>
Yep.
> Is there a strong reason why the file and data sizes were limited to
> 256/64K?
I presume by file you mean name.
In the various forms of an EA - shortform and leaf form, the
namelen is stored as 1 byte and so we can really only store 255 bytes
for a name AFAICT.
For the value part, I can see 3 forms in which it is short form or
in leaf-form with value local or value remote.
struct xfs_attr_sf_entry {
__uint8_t namelen; /* actual length of name (no NULL) */
__uint8_t valuelen; /* actual length of value (no NULL) */
typedef struct xfs_attr_leaf_name_local {
__be16 valuelen; /* number of bytes in value */
__u8 namelen; /* length of name bytes */
typedef struct xfs_attr_leaf_name_remote {
__be32 valueblk; /* block number of value bytes */
__be32 valuelen; /* number of bytes in value */
__u8 namelen; /* length of name bytes */
So from a valuelen pt-of-view we have 2^32-1.
Not sure about other limitations there.
I'm not sure why 64K was chosen for a value size limit.
In fact, on a quick look in the xfs code I can't see (other than in dmapi
and an assert in list) where we limit this.
We do limit it in the attr(1) userspace cmd by only reading up to
ATTR_MAX_VALUELEN.
1 xfs/xfs_attr.h <global> 56 #define ATTR_MAX_VALUELEN (64*1024)
2 dmapi/xfs_dm.c xfs_dm_bulkall_one 685 if (value_len > ATTR_MAX_VALUELEN)
3 dmapi/xfs_dm.c xfs_dm_bulkall_one 686 value_len = ATTR_MAX_VALUELEN;
4 dmapi/xfs_dm.c xfs_dm_get_config 1584 retval = ATTR_MAX_VALUELEN;
5 dmapi/xfs_dm.c xfs_dm_get_dmattr 1957 if (alloc_size > ATTR_MAX_VALUELEN)
6 dmapi/xfs_dm.c xfs_dm_get_dmattr 1958 alloc_size = ATTR_MAX_VALUELEN;
7 dmapi/xfs_dm.c xfs_dm_set_dmattr 2623 if (buflen > ATTR_MAX_VALUELEN)
8 xfs/xfs_attr.c xfs_attr_put_listent 682 ASSERT(context->count <
(ATTR_MAX_VALUELEN/8));
And on IRIX we limited the value size in the vfs and not in the xfs code.
I wonder what would happen going straight to the setxattr syscall on an
xfs file.
Okay, we are limited by:
#define XATTR_SIZE_MAX 65536 /* size of an extended attribute value (64k) */
And we have one for the name:
#define XATTR_NAME_MAX 255 /* # chars in an extended attribute name */
static long
setxattr(struct dentry *d, char __user *name, void __user *value,
size_t size, int flags)
{
...
if (size) {
if (size > XATTR_SIZE_MAX)
return -E2BIG;
So the Linux interface will limit us here too by the looks of it.
> Would they be hard to 'generalize' to max-path-segment-len/max-filelen?
>
> Only reason I wonder is wondering what file systems besides apple's
> "HPFS"(?) and
> MS's NTFS, that allow alternate data-streams of arbitrary length. I'm
> not sure about
> the maximums on HPFS and NTFS, but I haven't _read_ of any notable
> limits (I'm sure
> there are some, but it _seems_ you can store alternate file versions in
> different data-streams
> on NTFS, for example... I.e. could use it as a revision system,
> theoretically -- to save
> older versions of the file with the right software -- but with XFS, it
> wouldn't be so
> general case with a 64K data limit -- wouldn't be a show-stopper if one
> could 'link'
> multiple data-segments, but am just curious about the limitations (not
> that I'm planning
> on implementing a version control system using data-forks...it was just
> an example! :-)).
>
> linda
>
--Tim
|