linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Charles Manning <manningc2@actrix.gen.nz>
To: Dave Quigley <dpquigl@tycho.nsa.gov>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: What's a realistic size for xattr?
Date: Thu, 13 Mar 2008 13:03:53 +1300	[thread overview]
Message-ID: <200803131303.53679.manningc2@actrix.gen.nz> (raw)
In-Reply-To: <1205364753.2766.218.camel@moss-terrapins.epoch.ncsc.mil>

On Thursday 13 March 2008 12:32:33 Dave Quigley wrote:
> On Thu, 2008-03-13 at 11:06 +1300, Charles Manning wrote:
> > I'm trying to figure out a reasonable approach to implementing xattr in
> > YAFFS.
> >
> > >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?...
> >
> > Thanx.
> >
> > Charles
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> 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.
>
> Dave


Is that 128 characters per xattr value or for the whole set of xattribs 
attached to a file?

What I'm trying to figure out is a reasonable size for all the xattribs 
together. ie. If I store xattribs as a single blob containing all the 
name:value pairs, how big will that blob need to be?

I should have perhaps given some extra context here.

I'm trying to find the bang-for-bucks trade-off point for a simple 
implementation.

YAFFS is a flash file system and is typically used in embedded systems 
(phones, routers, printers, point-of-sale,... etc). I guess limited use of 
SELinux is a reasonable benchmark for what is used here.

Huge fs for corporate servers don't really fit in this picture so I guess 
vastly complex ACLs , while theoretically possible, don't really fall into 
the yaffs space.







  reply	other threads:[~2008-03-13  0:04 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 [this message]
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
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=200803131303.53679.manningc2@actrix.gen.nz \
    --to=manningc2@actrix.gen.nz \
    --cc=dpquigl@tycho.nsa.gov \
    --cc=linux-fsdevel@vger.kernel.org \
    /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).