Per-filesystem default mount options

[midenok]

LOR thread

Got an answer from Karel, can work now!

On Sat, Oct 19, 2013 at 08:03:29AM +0400, Aleksey Midenkov wrote:

On Fri, Oct 18, 2013 at 12:34 PM, Karel Zak [email protected] wrote:

On Wed, Oct 16, 2013 at 06:13:17PM +0400, Aleksey Midenkov wrote:

Is it possible to specify per-filesystem default mount options
somewhere in configuration file?

/etc/fstab, or tune2fs for extN, or /etc/nsfmount.conf for NFS.

The per-filesystem-type default options are also hardcoded in kernel.

I'm sorry for my misguide and, perhaps, a wrong start. What I mean is
per-fs type default mount options. That's true, they are hardcoded in
kernel. But, there is a need to have them customized. I know, there is
ton of user-level utils that maybe can provide it. But... I feel that
this basic feature is important for the core. That's why I decided to
ask here in hope that you will discuss this with me.

If you really need a generic (on device independent solution), then I
don't see a better way than improve libmount for read something
like /etc/mount/.conf. The problem is that such feature will
not be usable for non-libmount applications.

I keep stumbling upon this lack for a million-th times for as long as
15 years. Every barely installed host, f.ex. even routers that have no
ability to install another utils except the 'mount', they require me
each time to put charset from command line. And you know, this is the
common source for errors for non-latin countries like your servant's.

I understand the pain for removable media, but for regular disks you
can use /etc/fstab, right?

When charset option is forgotten the filenames are garbled after copy.
And you not always notice it because non-latin ones are somewhere deep
inside. But after some time passed you see the surprise...

I understand.

[ghost]

Alright, at first let's think whether we should use /etc/mount/defaults.conf or something better (e.g. /etc/fstab?). Is there an ability to extend /etc/fstab? What would it look like if there is.

[midenok]

A bit from my fstab:

# ...
# <filesystem> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0

/dev/sda2       /               ext4    defaults,errors=remount-ro,noatime,discard,nobarrier 0       1
LABEL=slim:/usr /usr            ext4    defaults,noatime,discard,nobarrier 0 1
LABEL=slim:/var /var            ext4    defaults,noatime,discard,nobarrier 0 1
LABEL=slim:/home /home          ext4    defaults,noatime,discard,nobarrier 0 1

I guess, we can add special character for <filesystem> and <mount point> fields (first guess it should be *):

# ...
# <filesystem> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0

# Rule 1
*                 *             ext4     noatime,discard,nobarrier

/dev/sda2        /              ext4     defaults,errors=remount-ro     0       1
LABEL=slim:/usr  /usr           ext4     defaults  0 1
LABEL=slim:/var  /var           ext4     defaults  0 1
LABEL=slim:/home /home          ext4     defaults  0 1

# Rule 2
*                 *             ext4     defaults

Default rules should influence all the following records, but new default rules should override them. In the example above Rule 1 specifies options for next 4 rules and Rule 2 recovers conventional (compiled-in) defaults. So that mount -t ext4 will work as normally expected (as it would do without /etc/fstab).

[ghost]

Should we override them? Why not to merge?

Pros:

• we can add some additional params explicitly calling mount and not worrying we forgot to add for example an iocharset parameter;
• we can do chmod +s mount with "* * vfat ro" set allowing one to mount external devices read only.

Cons:

• it changes the default behavior of mount;
• it could be not very obvious.

[midenok]

Override is only for default rules (with same <type>). For all other rules (including options specified from command-line) it is merge. Otherwise, there would be no initial sense.

P.S. Well, I'm not sure about compiled-in defaults. Should we override them or merge... I guess, it is better to override because it gives more control.

[ghost]

And yes, in my opinion, changing the fstab syntax in such a way is not a very nice idea. It breaks backward compatibility, and I find this inadmissible.

[midenok]

In fact, it is admissible. LABEL= semantics also had broke backward compatibility, but no one had suffered from that. Because -- if you need backward compatibility you just don't use new semantics. And if you start using new semantics you agree that it will be incompatible. /etc/fstab is host-bound file, it doesn't meant to be interchanged between many hosts. I can't see any use cases where it could bring conflict.

[ghost]

In the example above Rule 1 specifies options for next 4 rules
Override is only for default rules

Oh, now I see your point. OK, why not to do something like this:

# <filesystem> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda2        /              ext4     defaults,errors=remount-ro     0       1
LABEL=slim:/usr  /usr           ext4     defaults  0 1
LABEL=slim:/var  /var           ext4     defaults  0 1
LABEL=slim:/home /home          ext4     defaults  0 1

# Rule
*                 *             ext4     defaults,iocharset=utf8

That means that we merge these dicts while either mounting /dev/sda2 or calling "mount -t ext4 /dev/sdb1 /mnt/external". And I'm still not very satisfied with this syntax.

[midenok]

Rule 1 is just for the sake of brevity (i.e. to add options noatime,discard,nobarrier to mountpoints /, /usr, /var, /home). This was an example of how to make fstab to look cleaner. Btw, default iocharset is the main reason why I started this topic.

[ghost]

Example:

# <filesystem> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda2        /              ext4     defaults,errors=remount-ro  0 1
LABEL=slim:/usr  /usr           ext4     defaults  0 1
LABEL=slim:/home /home          ext4     defaults  0 1
proc             /proc          proc     defaults  0 0

# Rule
*                 *             ext4     noatime,discard,nobarrier,iocharset=utf8
*                 *             vfat     ro,codepage=866,iocharset=utf8

Suppose you also had called "mount -t vfat /dev/sdb1 /mnt/external". According to the config above your devices would have been mounted like this:

proc on /proc type proc (rw,noexec,nosuid,nodev)
/dev/sda2 on / type ext4 (rw,noatime,discard,nobarrier,iocharset=utf8,errors=remount-ro)
LABEL=slim:/usr on /usr type ext4 (rw,noatime,discard,nobarrier,iocharset=utf8)
LABEL=slim:/home on /home type ext4 (rw,noatime,discard,nobarrier,iocharset=utf8)
/dev/sdb1 on /mnt/external type vfat (ro,codepage=866,iocharset=utf8)

What do you think?

[midenok]

Oh, I see. This will give less control. F.ex. if you want to create another section of ext4 mounts in fstab with bunch of different default options. Or need a rule without any default options at all (but need these default options in another places).

[ghost]

OK, I find your arguments conclusive. Now, what's the main scenarios for using this feature?

[midenok]

Well, after some time of thinking I can remember more practical uses.
options for all:

• sync/async
• atime/noatime
• exec/noexec
• rw/ro

options for ext3:

• commit

options for fat:

• uid, gid
• umask
• dmask
• fmask
• check

All these options would benefit from setting in defaults. I think, we could even do more sophisticated rules by adding device masks. F.ex.:

# Rule
DEFAULT=/dev/sd*                 *             ext4     noatime,discard,nobarrier,iocharset=utf8

But I can't imagine for now how much effort it will take.