From: Dave Chinner <david@fromorbit.com>
To: Jeff Liu <jeff.liu@oracle.com>
Cc: Sun_Blood <sblood@gmail.com>, xfs@oss.sgi.com
Subject: Re: Extended attributes limit in Linux
Date: Mon, 3 Feb 2014 08:37:11 +1100 [thread overview]
Message-ID: <20140202213711.GR2212@dastard> (raw)
In-Reply-To: <52EB64DC.4020603@oracle.com>
On Fri, Jan 31, 2014 at 04:54:52PM +0800, Jeff Liu wrote:
> Hello,
>
> On 01/31 2014 15:40 PM, Sun_Blood wrote:
> > Hello,
> >
> > If I understands it correctly XFS don't have a limit to the size of
> > extended attributes(EA) but Linux impose a limit at 64k.
> > What I am trying to do is build a backup server that our Apple computers
> > will use together with rsync to backup files to. The problem I face is
> > that Apple HFS+ don't have a limit to EA so it has files with more then
> > 64k of EA in it.
> >
> > The Linux Kernel has a limit imposed to it in include/linux/limits.h
> >
> > #defineXATTR_SIZE_MAX 65536 /* size of an extended attribute value
> > (64k) */
> >
> > #defineXATTR_LIST_MAX 65536 /* size of extended attribute namelist
> > (64k) */
> >
>
> Yes, 64k is the VFS limit per EA value size.
XFS has a limit of 64k as well. I suspect that we could handle
larger EAs without too much problem as we already have the concept
of a "remote EA" that is allocated outside of the attribute btree
(but still inside the attribute address space). The problem with
them is that they are written synchronously, and so large attributes
written this way are slow operations.
Still, until the VFS limit is lifted and we do a bunch more work to
avoid XATTR_SIZE_MAX allocations everywhere there's no point looking
at raising the XFS limit....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-02-02 21:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-31 7:40 Extended attributes limit in Linux Sun_Blood
2014-01-31 8:54 ` Jeff Liu
2014-01-31 10:44 ` Vyacheslav Dubeyko
2014-01-31 12:24 ` Jeff Liu
2014-01-31 12:52 ` Vyacheslav Dubeyko
2014-01-31 13:39 ` Jeff Liu
2014-01-31 14:21 ` Vyacheslav Dubeyko
2014-01-31 14:33 ` Jeff Liu
2014-01-31 19:25 ` Sun_Blood
2014-02-01 14:08 ` Vyacheslav Dubeyko
2014-02-02 14:33 ` Sun_Blood
2014-02-02 15:12 ` Jeff Liu
2014-02-02 15:22 ` Jeff Liu
2014-02-02 15:31 ` Sun_Blood
2014-02-03 1:15 ` Chris Murphy
2014-02-03 7:14 ` Sun_Blood
2014-02-03 20:51 ` Chris Murphy
2014-02-02 21:37 ` Dave Chinner [this message]
2014-02-03 7:19 ` Sun_Blood
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=20140202213711.GR2212@dastard \
--to=david@fromorbit.com \
--cc=jeff.liu@oracle.com \
--cc=sblood@gmail.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