* libmount: Is the 'defaults' option intentionally a no-op?
@ 2017-05-11 11:40 W. Trevor King
2017-05-11 12:24 ` Karel Zak
0 siblings, 1 reply; 6+ messages in thread
From: W. Trevor King @ 2017-05-11 11:40 UTC (permalink / raw)
To: util-linux
[-- Attachment #1: Type: text/plain, Size: 4701 bytes --]
I'm having trouble squaring the docs in mount(8) [1]:
defaults
Use the default options: rw, suid, dev, exec, auto, nouser, and
async.
Note that the real set of all default mount options depends on
kernel and filesystem type. See the beginning of this section
for more details.
and fstab(5) [2]:
defaults
use default options: rw, suid, dev, exec, auto, nouser, and async.
with the implementation [3]:
{ "defaults", 0, 0 }, /* default options */
where the struct fields are [4]:
* @name: option name[=type] where type is printf-like type specifier")
* @id: option ID or MS_* flags (e.g MS_RDONLY)
* @mask: MNT_{NOMTAB,INVERT,...} mask
As far as I can tell, that makes 'defaults' a no-op. For example, it
doesn't clear MS_RDONLY:
# strace -o /tmp/trace mount -t tmpfs -o ro,defaults - /tmp/a
# grep 'mount(' /tmp/trace
mount("-", "/tmp/a", "tmpfs", MS_MGC_VAL|MS_RDONLY, NULL) = 0
But using ‘rw’ directly does:
# strace -o /tmp/trace mount -t tmpfs -o ro,rw - /tmp/a
# grep 'mount(' /tmp/trace
mount("-", "/tmp/a", "tmpfs", MS_MGC_VAL, NULL) = 0
And as you can see in those strace logs, the presence of ‘defaults’ in
userspace_opts_map means that it doesn't get passed through in
mount(2)'s ‘data’ argument either.
I can think of a few possibilities:
a. ‘defaults’ is supposed to be a no-op placeholder for the fourth
fstab field. We should drop it from examples that set any other
options (like [5]) and update the man entries [1,2] to remove the
references to ‘rw’, ‘suid’, etc. and replace them with markers on
the inverted settings listed by:
$ git grep MNT_INVERT libmount/src/optmap.c
This makes it clear that ‘defaults’ doesn't *change* anything or
return you to the default values of some subset of settings.
b. ‘defaults’ is supposed to mean “zero mountflags” (and maybe also
“zero data”?). In this case, like case a, we should drop it from
examples that set any other options (like [5]). We should update
the man entries [1,2] to explain the clearing. But I don't know
why anyone would ever use this option except on its own as a
fourth-fstab-field placeholder (like case a). Presumably whoever
is inserting ‘defaults’ in the mount options could just remove all
the earlier entries (e.g. using "bar" instead of
"foo,defaults,bar").
c. ‘defaults’ is supposed to be shorthand for
‘rw,suid,dev,exec,auto,nouser,async’. It should be implemented
with something like:
{ "defaults", MS_RDONLY | MS_NOSUID | MS_NODEV | MS_NOEXEC | MNT_MS_NOAUTO | MNT_MS_USER | MS_SYNCHRONOUS, MNT_NOHLPS | MNT_INVERT | MNT_NOMTAB},
(although I have no idea if using MS_RDONLY flags in
userspace_opts_map is viable. It probably isn't).
Altenatively, it could be implemented by removing the entry from
userspace_opts_map and adding a pre-processing step that replaces
shorthand (e.g. mapping "foo,defaults,bar" →
"foo,rw,suid,dev,exec,auto,nouser,async,bar") before iterating over
the options in mnt_context_merge_mflags. The man entries [1,2] are
fine.
d. I'm missing something obvious ;). We may want some really small
words in mount(8) to keep others from falling into the same
misunderstanding that I've fallen into.
Regardless of which case is correct, we may want to annotate the
inverted flags (as I mentioned in case a), since that (combined with
the existing default caveats in [6]) explains the “we will call
something close to mount(source, target, filesystemtype, 0, NULL)”
starting point, and folks might not think “let me look up the
‘defaults’ docs…” when they're trying to figure out if the default is
dev or nodev, etc.
Thoughts?
Trevor
[1]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/mount.8?h=v2.29.2#n935
[2]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/fstab.5?h=v2.29.2#n172
[3]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/libmount/src/optmap.c?h=v2.29.2#n138
[4]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/libmount/src/libmount.h.in?h=v2.29.2#n58
[5]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/fstab.5?h=v2.29.2#n65
[6]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/mount.8?h=v2.29.2#n824
--
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: libmount: Is the 'defaults' option intentionally a no-op? 2017-05-11 11:40 libmount: Is the 'defaults' option intentionally a no-op? W. Trevor King @ 2017-05-11 12:24 ` Karel Zak 2017-05-11 13:48 ` [PATCH] WIP: mount.8: Split out fstab-specific mount options W. Trevor King 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2017-05-11 12:24 UTC (permalink / raw) To: W. Trevor King; +Cc: util-linux On Thu, May 11, 2017 at 04:40:32AM -0700, W. Trevor King wrote: > I'm having trouble squaring the docs in mount(8) [1]: > > defaults > Use the default options: rw, suid, dev, exec, auto, nouser, and > async. > > Note that the real set of all default mount options depends on > kernel and filesystem type. See the beginning of this section > for more details. ... > As far as I can tell, that makes 'defaults' a no-op. For example, it > doesn't clear MS_RDONLY: > > # strace -o /tmp/trace mount -t tmpfs -o ro,defaults - /tmp/a > # grep 'mount(' /tmp/trace > mount("-", "/tmp/a", "tmpfs", MS_MGC_VAL|MS_RDONLY, NULL) = 0 > > But using ‘rw’ directly does: > > # strace -o /tmp/trace mount -t tmpfs -o ro,rw - /tmp/a > # grep 'mount(' /tmp/trace > mount("-", "/tmp/a", "tmpfs", MS_MGC_VAL, NULL) = 0 That's true and expected. > And as you can see in those strace logs, the presence of ‘defaults’ in > userspace_opts_map means that it doesn't get passed through in > mount(2)'s ‘data’ argument either. > > I can think of a few possibilities: > > a. ‘defaults’ is supposed to be a no-op placeholder for the fourth > fstab field. We should drop it from examples that set any other > options (like [5]) and update the man entries [1,2] to remove the > references to ‘rw’, ‘suid’, etc. and replace them with markers on > the inverted settings listed by It's placeholder, but kernel uses some options like "rw,exec,suid" by default, so it's described in the man page... I agree the description and relation between kernel defaults and the placeholder should be described more clearly. > c. ‘defaults’ is supposed to be shorthand for > ‘rw,suid,dev,exec,auto,nouser,async’. It should be implemented > with something like: No way, we really don't want to do any default setting in userspace. My suggestion (man page): default No-op placeholder with no impact to the filesystem mount options. The real mount options depends on built-in kernel defaults and default mount options defined by filesystem superblock. The usual kernel behaviour is to mount filesystems with rw, suid and exec flags by default. See the beginning of this section for more details. The "default" is interpreted as "auto" by "mount -a". Is it better than the current description? Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] WIP: mount.8: Split out fstab-specific mount options 2017-05-11 12:24 ` Karel Zak @ 2017-05-11 13:48 ` W. Trevor King 2017-05-12 7:54 ` Karel Zak 0 siblings, 1 reply; 6+ messages in thread From: W. Trevor King @ 2017-05-11 13:48 UTC (permalink / raw) To: util-linux; +Cc: Karel Zak, W. Trevor King And list the default settings for the X/noX pairs. This clears up some ambiguity around the meaning of "defaults" and fills in some entries missing from the earlier man pages. Signed-off-by: W. Trevor King <wking@tremily.us> --- 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? > My suggestion (man page): > > default > > No-op placeholder with no impact to the filesystem mount options. > > The real mount options depends on built-in kernel defaults and > default mount options defined by filesystem superblock. The usual > kernel behaviour is to mount filesystems with rw, suid and exec > flags by default. See the beginning of this section for more details. > > 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 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?). sys-utils/fstab.5 | 33 +---------- sys-utils/mount.8 | 164 ++++++++++++++++++++++++++++++------------------------ 2 files changed, 95 insertions(+), 102 deletions(-) diff --git a/sys-utils/fstab.5 b/sys-utils/fstab.5 index 07d0287..16f6662 100644 --- a/sys-utils/fstab.5 +++ b/sys-utils/fstab.5 @@ -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 .RE .B The first field @@ -155,39 +155,12 @@ deprecated). .RS This field describes the mount options associated with the filesystem. -It is formatted as a comma-separated list of options. -It contains at least the type of mount -.RB ( ro -or -.BR rw ), -plus any additional options appropriate to the filesystem -type (including performance-tuning options). +It is formatted as a comma-separated list of options, which may depend +on the filesystem type (including performance-tuning options). For details, see .BR mount (8) or .BR swapon (8). - -Basic filesystem-independent options are: -.TP -.B defaults -use default options: rw, suid, dev, exec, auto, nouser, and async. -.TP -.B noauto -do not mount when "mount -a" is given (e.g., at boot time) -.TP -.B user -allow a user to mount -.TP -.B owner -allow device owner to mount -.TP -.B comment -or -.B x-<name> -for use by fstab-maintaining programs -.TP -.B nofail -do not report errors for this device if it does not exist. .RE .B The fifth field diff --git a/sys-utils/mount.8 b/sys-utils/mount.8 index bbfe71b..e39ada7 100644 --- a/sys-utils/mount.8 +++ b/sys-utils/mount.8 @@ -643,7 +643,8 @@ a comma-separated list. For example: .RE For more details, see the -.B FILESYSTEM-INDEPENDENT MOUNT OPTIONS +.B FILESYSTEM-INDEPENDENT MOUNT OPTIONS\fR, +.B FSTAB-SPECIFIC MOUNT OPTIONS\fR, and .B FILESYSTEM-SPECIFIC MOUNT OPTIONS sections. @@ -821,9 +822,6 @@ Display version information and exit. Display help text and exit. .SH FILESYSTEM-INDEPENDENT MOUNT OPTIONS -Some of these options are only useful when they appear in the -.I /etc/fstab -file. Some of these options could be enabled or disabled by default in the system kernel. To check the current setting see the options @@ -837,7 +835,7 @@ mounted (but not every filesystem actually honors them \(en e.g.\&, the option today has an effect only for ext2, ext3, fat, vfat and ufs): .TP -.B async +.B async \fR(default) All I/O to the filesystem should be done asynchronously. (See also the .B sync option.) @@ -848,21 +846,11 @@ by kernel defaults. See also the descriptions of the \fB\%relatime\fR and .B strictatime mount options. .TP -.B noatime +.B noatime \fR(default) Do not update inode access times on this filesystem (e.g.\& for faster access on the news spool to speed up news servers). This works for all inode types (directories too), so it implies \fB\%nodiratime\fR. .TP -.B auto -Can be mounted with the -.B \-a -option. -.TP -.B noauto -Can only be mounted explicitly (i.e., the -.B \-a -option will not cause the filesystem to be mounted). -.TP .na .BR context=\fIcontext ", " fscontext=\fIcontext ", " defcontext=\fIcontext ", and " \%rootcontext=\fIcontext .ad @@ -936,22 +924,15 @@ For more details, see .RE .TP -.B defaults -Use the default options: -.BR rw ", " suid ", " dev ", " exec ", " auto ", " nouser ", and " async . - -Note that the real set of all default mount options depends on kernel -and filesystem type. See the beginning of this section for more details. -.TP -.B dev +.B dev \fR(default) Interpret character or block special devices on the filesystem. .TP .B nodev Do not interpret character or block special devices on the file system. .TP -.B diratime -Update directory inode access times on this filesystem. This is the default. +.B diratime \fR(default) +Update directory inode access times on this filesystem. (This option is ignored when \fBnoatime\fR is set.) .TP .B nodiratime @@ -963,7 +944,7 @@ All directory updates within the filesystem should be done synchronously. This affects the following system calls: creat, link, unlink, symlink, mkdir, rmdir, mknod and rename. .TP -.B exec +.B exec \fR(default) Permit execution of binaries. .TP .B noexec @@ -971,25 +952,17 @@ Do not permit direct execution of any binaries on the mounted filesystem. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.) .TP -.B group -Allow an ordinary user to mount the filesystem if one -of that user's groups matches the group of the device. -This option implies the options -.BR nosuid " and " nodev -(unless overridden by subsequent options, as in the option line -.BR group,dev,suid ). -.TP .B iversion Every time the inode is modified, the i_version field will be incremented. .TP -.B noiversion +.B noiversion \fR(default) Do not increment the i_version inode field. .TP .B mand Allow mandatory locks on this filesystem. See .BR fcntl (2). .TP -.B nomand +.B nomand \fR(default) Do not allow mandatory locks on this filesystem. .TP .B _netdev @@ -1016,7 +989,7 @@ option is required to obtain traditional semantics. In addition, since Linux 2.6.30, the file's last access time is always updated if it is more than 1 day old. .TP -.B norelatime +.B norelatime \fR(default) Do not use the .B relatime feature. See also the @@ -1032,7 +1005,7 @@ or but still allow userspace to override it. For more details about the default system mount options see /proc/mounts. .TP -.B nostrictatime +.B nostrictatime \fR(default) Use the kernel's default behavior for inode access time updates. .TP .B lazytime @@ -1058,10 +1031,10 @@ or .RE .sp .TP -.B nolazytime +.B nolazytime \fR(default) Do not use the lazytime feature. .TP -.B suid +.B suid \fR(default) Allow set-user-ID or set-group-ID bits to take effect. .TP @@ -1072,17 +1045,9 @@ effect. .B silent Turn on the silent flag. .TP -.B loud +.B loud \fR(default) Turn off the silent flag. .TP -.B owner -Allow an ordinary user to mount the filesystem if that -user is the owner of the device. -This option implies the options -.BR nosuid " and " nodev -(unless overridden by subsequent options, as in the option line -.BR owner,dev,suid ). -.TP .B remount Attempt to remount an already-mounted filesystem. This is commonly used to change the mount flags for a filesystem, especially to make a @@ -1124,28 +1089,6 @@ All I/O to the filesystem should be done synchronously. In the case of media with a limited number of write cycles (e.g.\& some flash drives), \fBsync\fR may cause life-cycle shortening. .TP -.B user -Allow an ordinary user to mount the filesystem. -The name of the mounting user is written to the mtab file (or to the private -libmount file in /run/mount on systems without a regular mtab) so that this -same user can unmount the filesystem again. -This option implies the options -.BR noexec ", " nosuid ", and " nodev -(unless overridden by subsequent options, as in the option line -.BR user,exec,dev,suid ). -.TP -.B nouser -Forbid an ordinary user to mount the filesystem. -This is the default; it does not imply any other options. -.TP -.B users -Allow any user to mount and to unmount the filesystem, even -when some other ordinary user mounted it. -This option implies the options -.BR noexec ", " nosuid ", and " nodev -(unless overridden by subsequent options, as in the option line -.BR users,exec,dev,suid ). -.TP .B X-* All options prefixed with "X-" are interpreted as comments or as userspace application-specific options. These options are not stored in the user space (e.g. mtab file), @@ -1175,6 +1118,83 @@ in octal notation. The default mode is 0755. This functionality is supported only for root users. The option is also supported as x-mount.mkdir, this notation is deprecated for mount.mkdir since v2.30. +.SH FSTAB-SPECIFIC MOUNT OPTIONS +The following options apply only to fstab entries and are not useful when calling +.BR mount +directly. +See +.BR fstab (5) +for more details on the file format. + +.TP +.B auto +Can be mounted with the +.B \-a +option (e.g., at boot time). +.TP +.B noauto \fR(default) +Can only be mounted explicitly (i.e., the +.B \-a +option will not cause the filesystem to be mounted). +.TP +.B comment=* +All options prefixed with +.BR comment= +are interpreted as comments or as userspace application-specific options. +These options are not stored in the user space (e.g. mtab file), +nor sent to the mount.\fItype\fR helpers nor to the +.BR mount (2) +system call. The suggested format is \fBcomment=\fIappname\fR.\fIoption\fR. +.TP +.B defaults +A synonym for \fBauto\fR. +.TP +.B group +Allow an ordinary user to mount the filesystem if one +of that user's groups matches the group of the device. +This option implies the options +.BR nosuid " and " nodev +(unless overridden by subsequent options, as in the option line +.BR group,dev,suid ). +.TP +.B nogroup \fR(default) +Unset \fBgroup\fR. +.TP +.B owner +Allow an ordinary user to mount the filesystem if that +user is the owner of the device. +This option implies the options +.BR nosuid " and " nodev +(unless overridden by subsequent options, as in the option line +.BR owner,dev,suid ). +.TP +.B noowner \fR(default) +Unset \fBowner\fR. +.TP +.B user +Allow an ordinary user to mount the filesystem. +The name of the mounting user is written to the mtab file (or to the private +libmount file in /run/mount on systems without a regular mtab) so that this +same user can unmount the filesystem again. +This option implies the options +.BR noexec ", " nosuid ", and " nodev +(unless overridden by subsequent options, as in the option line +.BR user,exec,dev,suid ). +.TP +.B nouser \fR(default) +Unset \fBuser\fR. +.TP +.B users +Allow any user to mount and to unmount the filesystem, even +when some other ordinary user mounted it. +This option implies the options +.BR noexec ", " nosuid ", and " nodev +(unless overridden by subsequent options, as in the option line +.BR users,exec,dev,suid ). +.TP +.B nousers \fR(default) +Unset \fBusers\fR. + .SH "FILESYSTEM-SPECIFIC MOUNT OPTIONS" The following options apply only to certain filesystems. We sort them by filesystem. They all follow the -- 2.1.0.60.g85f0837 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] WIP: mount.8: Split out fstab-specific mount options 2017-05-11 13:48 ` [PATCH] WIP: mount.8: Split out fstab-specific mount options W. Trevor King @ 2017-05-12 7:54 ` Karel Zak 2017-05-12 17:36 ` W. Trevor King 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2017-05-12 7:54 UTC (permalink / raw) To: W. Trevor King; +Cc: util-linux On Thu, May 11, 2017 at 06:48:54AM -0700, W. Trevor King wrote: > And list the default settings for the X/noX pairs. This clears up > some ambiguity around the meaning of "defaults" and fills in some > entries missing from the earlier man pages. > > Signed-off-by: W. Trevor King <wking@tremily.us> > --- > 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). > > The real mount options depends on built-in kernel defaults and > > default mount options defined by filesystem superblock. The usual > > kernel behaviour is to mount filesystems with rw, suid and exec > > flags by default. See the beginning of this section for more details. > > > > 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". > 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. > sys-utils/fstab.5 | 33 +---------- > sys-utils/mount.8 | 164 ++++++++++++++++++++++++++++++------------------------ > 2 files changed, 95 insertions(+), 102 deletions(-) > > diff --git a/sys-utils/fstab.5 b/sys-utils/fstab.5 > index 07d0287..16f6662 100644 > --- a/sys-utils/fstab.5 > +++ b/sys-utils/fstab.5 > @@ -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 LABEL=MyOptDev /opt ext4 auto,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). > .SH FILESYSTEM-INDEPENDENT MOUNT OPTIONS > -Some of these options are only useful when they appear in the > -.I /etc/fstab > -file. > > Some of these options could be enabled or disabled by default > in the system kernel. To check the current setting see the options > @@ -837,7 +835,7 @@ mounted (but not every filesystem actually honors them \(en e.g.\&, the > option today has an effect only for ext2, ext3, fat, vfat and ufs): > > .TP > -.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). > +.SH FSTAB-SPECIFIC MOUNT OPTIONS > +The following options apply only to fstab entries and are not useful when calling > +.BR mount > +directly. Not true. mount(8) does not care about mount options source. (Yes, "defaults" is placeholder that makes sense only in fstab, but it's not an error to use it on command line, etc.). 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 async ... atime ... .SS User-space mount options default ... auto ... Does it make more sense? Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] WIP: mount.8: Split out fstab-specific mount options 2017-05-12 7:54 ` Karel Zak @ 2017-05-12 17:36 ` W. Trevor King 2017-05-16 12:41 ` Karel Zak 0 siblings, 1 reply; 6+ messages in thread From: W. Trevor King @ 2017-05-12 17:36 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux [-- Attachment #1: Type: text/plain, Size: 7665 bytes --] 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 #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] WIP: mount.8: Split out fstab-specific mount options 2017-05-12 17:36 ` W. Trevor King @ 2017-05-16 12:41 ` Karel Zak 0 siblings, 0 replies; 6+ messages in thread From: Karel Zak @ 2017-05-16 12:41 UTC (permalink / raw) To: W. Trevor King; +Cc: util-linux On Fri, May 12, 2017 at 10:36:29AM -0700, W. Trevor King wrote: > 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’. Unfortunately no. It's strange, but "mount -a" search for "noauto" and do not evaluate the options as flags. The libmount follows the original mount(8) with this behavior. I'll try to fix it. > * 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. Yes, "defaults" is just zero, no-op. > > > 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? If you want to store some mount option in users-space then use x-* on command line makes sense. For example systemd execs mount(8) and they do not have to use fstab (they may use systemd.mount unit) or generate mount on-the-fly by another way. > 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 You think about it too much :-))) The "default" is just placeholder. > 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.) This is true (but, we don't plan to make "noauto" default :-). > 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 I think it's fine to say that default are very basic things like "rw, suid, dev, exec, auto, nouser, async" but nothing else. (Sorry, in my previous reply I have selected "async" as bad example.) If you don't want to rely on kernel defaults then you have to explicit in your fstab. That's all. BTW, to make it more complicated... we have also FS specific options, and FS specific defaults and in many case it's possible to change it per-superblok by tools like tune2fs In this case the default will be different for sda1 and sda2. > 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 "rw" is no-op, kernel API has nothing like RW flag (we have MS_RDONLY). It's still possible that your device will be mounted read-only (pretty common for NFS exported read-only) or mount(8) will try another attempt with MS_RDONLY flag (maybe disabled by -w on command line). The reason is that mount ro is usually better than don't mount nothing. > 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 yes ... > I think documenting the kernel defaults is useful (less digging for > interested users). The very basic options are described in mount(2) syscall man page with some info about versions etc. Maybe we can re-use this information in mount(8) for the basic options. (And from pedantic point of view, it's possible to backport kernel features (pretty common for enterprise long time supported kernels), so all information about kernel versions maybe inaccurate..) > 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. I still believe that it would be better to add some generic description about defaults where we can describe that nothing 100% than add the WARNING. > > 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. Thanks. > Would you like me to work that up > now, or would you rather kick around the other issues above more > before a reroll? Maybe we can do it in more steps (patches): 1) for the fstab.5 -> mount.8 and "Generic kernel mount options" subsection 2) describe "defaults" placeholders and cleanup the examples 3) add info about default+versions from mount(2) to mount(8) Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-05-16 12:41 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-11 11:40 libmount: Is the 'defaults' option intentionally a no-op? W. Trevor King 2017-05-11 12:24 ` Karel Zak 2017-05-11 13:48 ` [PATCH] WIP: mount.8: Split out fstab-specific mount options W. Trevor King 2017-05-12 7:54 ` Karel Zak 2017-05-12 17:36 ` W. Trevor King 2017-05-16 12:41 ` Karel Zak
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.