All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <Joel.Becker@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] [RFC] Mount option trap for users
Date: Wed, 14 Oct 2009 03:03:35 -0700	[thread overview]
Message-ID: <20091014100335.GB4530@mail.oracle.com> (raw)
In-Reply-To: <20091014094129.GA12701@duck.suse.cz>

On Wed, Oct 14, 2009 at 11:41:29AM +0200, Jan Kara wrote:
> On Tue 13-10-09 17:38:59, Joel Becker wrote:
> > 	You *are* paying attention :-)  I believe this is for hysterical
> > raisins.  We copied ext3 on this.  I'm totally in support of ripping
> > ACLs out of Kconfig.
>   Yes, this would certainly simplify the situation. And looking at the
> code, disabling CONFIG_OCFS2_POSIX_ACL does not seem to bring any
> significant code-size or speed advantage... So I'm in favor of this.

	So let's do this:

1) Rip out CONFIG_OCFS2_POSIX_ACL.  The code is always built in.
2) Always enable acls if a filesystem has xattrs.  This is a noop if no
   one ever calls setacl.
3) If a user explicitly puts -oacl on the mount command line, but the
   filesystem doesn't have xattrs, fail the mount.  This is a safe place
   to catch people changing kernels, as a too-old kernel driver likely
   doesn't have xattrs anyway.
4) If a user explicitly puts -onoacl on the mount command line, they get
   what they asked for.

	This behavior matches the other 'modern' filesystems.  The only
weirdness is in the cluster case, and the most common users will be
using released versions with ACL support.  Anyone compiling recent
drivers or kernels can't leave the support out.
	Mark, Jan?

Joel

-- 

Life's Little Instruction Book #197

	"Don't forget, a person's greatest emotional need is to 
	 feel appreciated."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

  reply	other threads:[~2009-10-14 10:03 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
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 [this message]
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=20091014100335.GB4530@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.