public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: hooanon05@yahoo.co.jp
To: "David P. Quigley" <dpquigl@tycho.nsa.gov>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/8] Aufs2 documents
Date: Fri, 27 Feb 2009 23:27:17 +0900	[thread overview]
Message-ID: <16503.1235744837@jrobl> (raw)
In-Reply-To: <1235668827.15148.422.camel@moss-terrapins.epoch.ncsc.mil>


"David P. Quigley":
> an EOPNOTSUPP back. Considering things such as ACLs and SELinux labels
> are stored in xattrs it seems that failing a copyup on EOPNOTSUPP is a
> very reasonable thing to do.

Do you mean ... ?
- if aufs and its lower branch fs support xattr but its upper branch
  doesn't, then some of copyup will fail.
- that is user's choice.


> > Finally I am considering to make some levels to support xattr.
> > - support minimum common set of key only (if such set exists)
> >   Here "minimum common set" means a group of key which are surely
> >   supported by all filesystems. Aufs will filter-out other keys.
> > - create a new internal status flag
> >   This flag is set when the type of all branches are same. When the flag
> >   is set, aufs will handle xattr by simply redirecting.
> > - create a new aufs mount option
> >   the option will select two behaviours (above).
> 
> So I don't think this is a good way of going about it. The idea of
> having some flag which indicates just relay to the lower filesystems if
> they are all the same completely ignores that you may have several file
> systems which all support the required namespaces. One example I can

When all branch filesystems support the required xattr even if thier
filesystem-type differ, user can specify the mount option (the thrid
level above) and all xattr will be handled. When any of xattr are not
supported by the upper branch fs, then copyup will fail.
Do I make my clear, or do I misunderstand you?


> If you have more questions about this feel free to ask. I don't have
> time to actually do work in this space but I can answer whatever
> questions you have.

I am afraid I don't fully understand what you wrote.
According to linux/Documentation/Smack.txt, "xattr support is not
strictly required". But for selinux (or other security mechanism), xattr
is neccessary as you wrote.
Please tell me the url where I should know about security label or
type. Particulary "iso9660_t" type, I don't know what it is.
And do you believe the lack of supporting xattr is critical for aufs to
be merged?


J. R. Okajima

  reply	other threads:[~2009-02-27 14:27 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-23  7:31 [RFC 0/8] Aufs2 documents hooanon05
2009-02-23  7:33 ` [RFC 1/8] Aufs2: introduction hooanon05
2009-02-23  7:34 ` [RFC 2/8] Aufs2: structure hooanon05
2009-02-23  9:13   ` Tomas M
2009-02-23  9:22     ` Tomas M
2009-02-24  8:13       ` New filesystem for Linux kernel Tomas M
2009-02-24 11:52         ` Miklos Szeredi
2009-02-24 13:18           ` hooanon05
2009-02-24 13:45             ` Tarkan Erimer
2009-02-24 13:57               ` hooanon05
2009-02-24 14:16                 ` Tarkan Erimer
2009-02-24 14:50             ` Miklos Szeredi
2009-02-24 16:26               ` hooanon05
2009-02-25 10:28                 ` Miklos Szeredi
2009-02-26  4:09                   ` hooanon05
2009-02-26  5:51               ` hooanon05
2009-02-26  5:55                 ` hooanon05
2009-02-24 14:15         ` Theodore Tso
2009-02-24 15:18           ` David P. Quigley
2009-02-24 15:41             ` hooanon05
2009-02-25 15:53               ` David P. Quigley
2009-02-26  4:21                 ` hooanon05
2009-02-25  7:31             ` Tomas M
2009-02-25  9:33               ` David Newall
2009-02-25  8:12           ` Tomas M
2009-02-26 14:31           ` Amit Kucheria
2009-02-23 14:23     ` [RFC 2/8] Aufs2: structure hooanon05
2009-02-23  7:35 ` [RFC 3/8] Aufs2: lookup hooanon05
2009-02-23  7:36 ` [RFC 4/8] Aufs2: branch hooanon05
2009-02-23  7:36 ` [RFC 5/8] Aufs2: wbr_policy hooanon05
2009-02-23  7:37 ` [RFC 6/8] Aufs2: fmode_exec hooanon05
2009-02-23  7:37 ` [RFC 7/8] Aufs2: mmap hooanon05
2009-02-23  9:18   ` Tomas M
2009-02-23 14:39     ` hooanon05
2009-02-23  7:38 ` [RFC 8/8] Aufs2: plan hooanon05
2009-02-25 17:50 ` [RFC 0/8] Aufs2 documents David P. Quigley
2009-02-25 19:07   ` Matthew Wilcox
2009-02-26  4:54   ` hooanon05
2009-02-26 17:20     ` David P. Quigley
2009-02-27 14:27       ` hooanon05 [this message]
2009-02-27 18:17         ` David P. Quigley
2009-02-28  8:04           ` hooanon05

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=16503.1235744837@jrobl \
    --to=hooanon05@yahoo.co.jp \
    --cc=dpquigl@tycho.nsa.gov \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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