public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* Question about extended attributes...
@ 2008-08-01  0:11 Linda A. Walsh
  2008-08-01  6:55 ` Timothy Shimmin
  0 siblings, 1 reply; 4+ messages in thread
From: Linda A. Walsh @ 2008-08-01  0:11 UTC (permalink / raw)
  To: xfs-oss

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?

Is there a strong reason why the file and data sizes were limited to 
256/64K?
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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question about extended attributes...
  2008-08-01  0:11 Question about extended attributes Linda A. Walsh
@ 2008-08-01  6:55 ` Timothy Shimmin
  2008-08-01 12:32   ` Dave Chinner
  0 siblings, 1 reply; 4+ messages in thread
From: Timothy Shimmin @ 2008-08-01  6:55 UTC (permalink / raw)
  To: Linda A. Walsh; +Cc: xfs-oss

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question about extended attributes...
  2008-08-01  6:55 ` Timothy Shimmin
@ 2008-08-01 12:32   ` Dave Chinner
  2008-08-04  5:13     ` Timothy Shimmin
  0 siblings, 1 reply; 4+ messages in thread
From: Dave Chinner @ 2008-08-01 12:32 UTC (permalink / raw)
  To: Timothy Shimmin; +Cc: Linda A. Walsh, xfs-oss

On Fri, Aug 01, 2008 at 04:55:29PM +1000, Timothy Shimmin wrote:
> 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'm not sure why 64K was chosen for a value size limit.

Because changes to EAs are journalled. Hence there must be a bound
size limit because log space is limited.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question about extended attributes...
  2008-08-01 12:32   ` Dave Chinner
@ 2008-08-04  5:13     ` Timothy Shimmin
  0 siblings, 0 replies; 4+ messages in thread
From: Timothy Shimmin @ 2008-08-04  5:13 UTC (permalink / raw)
  To: Dave Chinner, Linda A. Walsh; +Cc: xfs-oss

Dave Chinner wrote:
> On Fri, Aug 01, 2008 at 04:55:29PM +1000, Timothy Shimmin wrote:
>> 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'm not sure why 64K was chosen for a value size limit.
> 
> Because changes to EAs are journalled. Hence there must be a bound
> size limit because log space is limited.
> 
Yeah, good point.
Which I guess also reflects how we consider extended attributes
to be more for metadata.

--Tim

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-08-04  5:12 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-01  0:11 Question about extended attributes Linda A. Walsh
2008-08-01  6:55 ` Timothy Shimmin
2008-08-01 12:32   ` Dave Chinner
2008-08-04  5:13     ` Timothy Shimmin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox