On Fri, May 12, 2017 at 09:54:51AM +0200, Karel Zak wrote:
> On Thu, May 11, 2017 at 06:48:54AM -0700, W. Trevor King wrote:
> > On Thu, May 11, 2017 at 02:24:42PM +0200, Karel Zak wrote:
> > > It's placeholder, but kernel uses some options like
> > > "rw,exec,suid" by default…
> >
> > And these are “everying marked with MNT_INVERT in optmap.c as well
> > as whatever filesystem-specific defaults”, right?
>
> Well, inverted options may be used to invert previously used
> options. The way how the options has been set is arbitrary
> (default, remount, on command line invert fstab setting, etc.). You
> can use it together on the same command line
>
> mount -o async,noasync,foo,bar
>
> is pretty valid. The last used option win (=noasync).
Right, but the things with MNT_INVERT are the defaults (what you get
if none of the given options toggle the flag).
> > > The "default" is interpreted as "auto" by "mount -a".
> >
> > This last line means "defaults" is effectively a synonym for "auto" in
> > fstab, an presumably "auto" would always be preferred (because it more
>
> More precisely, mount -a cares about "noauto" only, everything else
> is "auto".
Is that really true? I think:
* ‘noauto,auto’ means the same thing as a bare ‘auto’.
* With your wording, I'd expect ‘noauto,defaults’ to also mean the
same thing as ‘auto’ or ‘defaults’. But looking at the code again,
It still looks like ‘defaults’ is a no-op (not clearing
MNT_MS_NOAUTO), so ‘noauto,defaults’ would be the same as ‘noauto’.
If those are both right, I think we should adjust my patch to say that
‘defaults’ is a no-op with no qualifications.
> > clearly marks the change from the "no flag bits set" initial
> > state). I've started roughing out a sketch of where I think this
> > should go below, although there are a number of things that I'm
> > not clear on (e.g. are the X-* and x-* options in the same boat as
> > comment=*? What is (no)sub about?).
>
> Yes, we use x- and X- for 3rd party options (e.g. x-systemd), the
> options are ignored for mount(2) syscall.
But are they only meaningful in fstab? Or are there use-cases where
people would use them when calling mount(8) directly?
> > @@ -62,7 +62,7 @@ The following is a typical example of an
> > entry:
> > .sp
> > .RS 7
> > -LABEL=t-home2 /home ext4 defaults,auto_da_alloc 0 2
> > +LABEL=t-home2 /home ext4 auto,auto_da_alloc 0 2
>
> I think it's fine to have an example with the placeholder, maybe add
> more lines to the example:
>
> LABEL=MyHomeDev /home ext4 defaults 0 2
I still don't see the point to using ‘defaults’ when you could have
the same config using the more explicit:
LABEL=MyHomeDev /home ext4 auto 0 2
On the other hand, there's nothing special about ‘auto’. You could
also pick:
LABEL=MyHomeDev /home ext4 rw 0 2
or any of the other MNT_INVERT options. Using ‘defaults’ says one of
a few things:
a. I have no preferences, and:
i. Opening mount(8) to see which of (no)auto is the default is more
work than I want to invest.
ii. I can't think of an option where I can rely on the kernel or
libmount to preserve the current default (e.g., there's a
chance that the kernel makes ro the default, and a chance that
libmount makes noauto the default, etc.)
b. I don't understand what ‘defaults’ does.
Case a seems like a very unlikely position. There may be users who
don't care what the (no)lazytime default is, but are there users who
don't care about (no)auto or ro/rw? Perhaps there are (and they can
use ‘defaults’ to get that behavior). Case b seems much more likely,
and I think using ‘defaults’ as the “typical example” will confuse
readers who expect the man-page writer to understand ‘defaults’ (and
so fall into case a.ii?). I think ‘auto’ and ‘rw’ are both extremely
likely to remain defaults, but the kernel would cause more backwards
compat issues by swapping the default there, so:
LABEL=MyHomeDev /home ext4 rw 0 2
is probably the best “typical example”. And the “paranoid example”
would be:
LABEL=MyHomeDev /home ext4 auto,rw 0 2
for “libmount might go crazy and change it's mind so I'm pinning the
current ‘auto’ default”.
> LABEL=MyOptDev /opt ext4 auto,auto_da_alloc 0 2
With ‘auto’ being a default that libmount is unlikely to change, the
example should probably be:
LABEL=MyOptDev /opt ext4 auto_da_alloc 0 2
> > -Basic filesystem-independent options are:
>
> It's probably good idea to maintain the options description on one place, but it
> would be nice to add note about mount(8), something like
>
> For filesystem-independent options see mount(8).
The paragraph before the line I removed ends with:
For details, see mount(8) or swapon(8).
and that line predates my patch.
> > -.B async
> > +.B async \fR(default)
>
> Please, don't use "(default)" there. We don't control what is the
> default. It does not have to be the same for all kernels (and kernel
> versions).
Hmm. True, I guess, although I'm not sure how the kernel would change
a default. Say Linux decides to make ‘sync’ the default. They add a
new MS_ASYNCHRONOUS and error out if somebody sets both MS_SYNCHRONOUS
and MS_ASYNCHRONOUS. After a number of years (during which we can
update the manpage to warn about the switch), they swap the default
when neither MS_SYNCHRONOUS nor MS_ASYNCHRONOUS is set. The updated
man page would be something like:
async (default before Linux 8.3)
…
sync (default in Linux 8.3 and later)
…
I think documenting the kernel defaults is useful (less digging for
interested users). In the very unlikely scenario that the kernel (or
libmount) swaps a default we will almost certainly have a long swap
time to update the docs in this way.
If either project sets up something where the default could be swapped
without warning (e.g. they provide bits for MS_FOO and MS_NOFOO and
make no statement about the planned kernel version for the default
swap), then we should definitely call that out explicitly:
foo (default in Linux 12.2)
Set foo.
WARNING: Future Linux may make nofoo the default value without
warning. Users who have a preference should explicitly set either
foo or nofoo to protect themselves from such an occurrence.
nofoo
Unset foo.
WARNING: Future Linux may make this the default value without
warning, see foo for details.
The only time you'd *not* be able to prepare users in the man page
would be if Linux or libmount just went and swapped the default
without providing developers with a migration plan. I think that's
unlikely enough that we can ignore it and just document the kernel
defaults.
> Maybe rather than "FSTAB-SPECIFIC ..." use two subsections, one for
> kernel and another for user-sapce:
>
> .SH FILESYSTEM-INDEPENDENT MOUNT OPTIONS
> .SS Generic kernel mount options
Sounds great; I'll do this in v2. Would you like me to work that up
now, or would you rather kick around the other issues above more
before a reroll?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Attachment:
signature.asc
Description: OpenPGP digital signature
