From: Joel Becker <Joel.Becker@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] [RFC] Mount option trap for users
Date: Tue, 13 Oct 2009 17:31:05 -0700 [thread overview]
Message-ID: <20091014003105.GO23257@mail.oracle.com> (raw)
In-Reply-To: <20091013235021.GW11402@wotan.suse.de>
On Tue, Oct 13, 2009 at 04:50:21PM -0700, Mark Fasheh wrote:
> On Tue, Oct 13, 2009 at 04:02:41PM -0700, Joel Becker wrote:
> > On Tue, Oct 13, 2009 at 03:50:14PM -0700, Mark Fasheh wrote:
> > > Hmm, regarding this part of the discussion - how do we know if the admin
> > > actually wants the proposed behavior? Presumably the admin in our ext3
> > > example has a good reason for working without acls for a time. Perhaps the
> > > same admin would like that ability on a cluster node, without having to
> > > unmount from all acl nodes in the cluster...
> >
> > I would think anyone would want the acl behavior coherent across
> > the cluster. Otherwise node 1 is setting an acl that node 2 promptly
> > ignores? Yuk! Especially since that admin could have accidentally
> > booted a non-ACL ocfs2 and not realize it?
>
> Well, we have to ask ourselves what the (theoretical) person remounting ext3
> without acls is doing that for. This isn't about the ext3 rules for mounting
> with acls as much as it's a question of "why would this happen?".
Sure. And with ext3 it's probably "I forgot the option" because
it defaults to off. With xfs, it would have to be a deliberate -onoacl.
Christoph, are you paying attention? Any thoughts?
> > I don't know that it is valid. But if we want to support it, we
> > can clearly differentiate between "my kernel doesn't support this" and
> > "I support it, but I was told noacl".
>
> Right, I am theorizing about the case of "I support it, but I was told
> noacl" which I don't see a good reason to disallow (even if a mount is
> mounted acl elsewhere)
That sort of thing fits obviously in the realm of "you asked for
it". So it's only a question of effort vs need. That is, we put in the
time to add the flexibility (and the potential confusion) because we
expect someone really has a valid use case.
> It might make more sense to look at this from the other direction. Say I'm
> a cluster admin and my nodes aren't currently using acls. Perhaps at some
> point in the future, I want to enable them (maybe so I can deploy a new app
> on my shared disk). Today, I could do this without taking down the entire
> cluster - I'd simply enable acls one node at a time. Once they were all back
> up with acl support, I could deploy my app without having lost any downtime.
> If we disallow this situation, I'd have to bring down the entire cluster to
> enable acls.
Well, if we go to a "acls are on by default" scenario, they're
already on. You just don't notice them because no one has used
setfacl() and the default acls match unix permissions ;-) Turning it
"on" just means calling setfacl().
The whole problem of "what to do when -oacl is specified" falls
out from our defaulting them off. We're the only "modern" filesystem
that does that.
Joel
--
"Conservative, n. A statesman who is enamoured of existing evils,
as distinguished from the Liberal, who wishes to replace them
with others."
- Ambrose Bierce, The Devil's Dictionary
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127
next prev parent reply other threads:[~2009-10-14 0:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-14 14:56 [Ocfs2-devel] [PATCH] [RFC] Mount option trap for users Jan Kara
2009-09-14 19:44 ` Joel Becker
2009-09-15 9:24 ` Jan Kara
2009-09-17 23:00 ` Mark Fasheh
2009-10-06 17:17 ` Jan Kara
2009-10-13 19:46 ` Joel Becker
2009-10-13 20:12 ` Jan Kara
2009-10-13 20:43 ` Joel Becker
2009-10-13 22:30 ` Jan Kara
2009-10-13 22:50 ` Mark Fasheh
2009-10-13 23:02 ` Joel Becker
2009-10-13 23:50 ` Mark Fasheh
2009-10-14 0:31 ` Joel Becker [this message]
2009-10-14 0:27 ` Christoph Hellwig
2009-10-14 0:38 ` Joel Becker
2009-10-14 9:41 ` Jan Kara
2009-10-14 10:03 ` Joel Becker
2009-10-14 10:09 ` Jan Kara
2009-10-14 16:27 ` Mark Fasheh
2009-10-14 18:11 ` Jan Kara
2009-10-14 20:03 ` Joel Becker
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=20091014003105.GO23257@mail.oracle.com \
--to=joel.becker@oracle.com \
--cc=ocfs2-devel@oss.oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.