From: Nicholas Miell <nmiell@comcast.net>
To: Jamie Lokier <jamie@shareable.org>
Cc: Dave Quigley <dpquigl@tycho.nsa.gov>,
Charles Manning <manningc2@actrix.gen.nz>,
linux-fsdevel@vger.kernel.org
Subject: Re: What's a realistic size for xattr?
Date: Thu, 13 Mar 2008 01:56:06 -0700 [thread overview]
Message-ID: <1205398566.12854.28.camel@entropy> (raw)
In-Reply-To: <20080313000737.GA12786@shareable.org>
On Thu, 2008-03-13 at 00:07 +0000, Jamie Lokier wrote:
> Dave Quigley wrote:
> > > >From my (limited) knowledge of xattr it seems that in theory you could store a
> > > multi-Mbyte database in xattr, but in practice a smaller size is far more
> > > reasonable. Clearly storing/managing a small blob is going to be a lot
> > > simpler.
> > >
> > > What is the cut off of a reasonable xattr blob size? 1kbytes? 2kbytes?...
> >
> > I just realized that I never really answered your question. I've yet to
> > see a reasonable SELinux context over 128 characters and Smack labels
> > should be shorter than that. I don't know what beagle places in xattrs
> > but I think that would be a good place to take a look for more practical
> > xattr sizes.
>
> People copy files from other systems using rsync, so it's not just
> Linux uses of xattrs. Also, some programs can store their own data,
> such as search metadata, desktop metadata, checksums, descriptions
> (similar to MP3 id tags, but in xattrs) and all sorts of things.
>
> On Macs, xattrs are used to store the "resource fork", which contains
> icons etc. so can be quite large. Of course that's not done on Linux.
> People do sometimes try to copy those files to Linux and back, and it
> generally fails because Linux refuses the large xattrs.
>
> -- Jamie
Linux xattrs are nothing more than named extensions to struct stat. It's
unfortunate that Solaris reused the xattr name for a completely
different concept that already had existing names (named streams AKA
forks), but they aren't equivalent and are not intended to be
equivalent.
Pretending that xattrs are named streams is just a path to madness and
suffering, considering the Linux API is based around atomic attribute
querying and modification instead of the standard Unix I/O primitives
and the Powers That Be are vehemently against the implementation of
named streams in the Linux VFS.
--
Nicholas Miell <nmiell@comcast.net>
next prev parent reply other threads:[~2008-03-13 8:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-12 22:06 What's a realistic size for xattr? Charles Manning
2008-03-12 23:03 ` Nathan Scott
2008-03-12 23:23 ` Dave Quigley
2008-03-12 23:32 ` Dave Quigley
2008-03-13 0:03 ` Charles Manning
2008-03-13 17:10 ` Dave Quigley
2008-03-13 0:07 ` Jamie Lokier
2008-03-13 0:27 ` Brad Boyer
2008-03-13 8:56 ` Nicholas Miell [this message]
2008-03-13 3:45 ` Andreas Dilger
2008-03-15 11:09 ` Florian Weimer
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=1205398566.12854.28.camel@entropy \
--to=nmiell@comcast.net \
--cc=dpquigl@tycho.nsa.gov \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=manningc2@actrix.gen.nz \
/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;
as well as URLs for NNTP newsgroup(s).