vfs_donmount: in certain cases try r/o mount if r/w mount fails

[avg]

Summary

If the operation is not an update, if neither r/w nor r/o mode is
explicitly requested and if the error code hints at the possibility
of the media being read-only, then we can try to automatically
downgrade to the readonly mode.

This is especially useful for auto-mounting of removable media
that sometimes can happen to be write-protected.

[kib]

Such level of artificial intelligence was never applied to the Unix behavior. IMO we should not out-guess the user, and if the requested mode of operation failed, to not retry with randomly tweaked parameters.

For instance, we do not guess the filesystem type in the kernel. Why rw/ro should be different ?

[avg]

In D13361#278943, @kib wrote:

For instance, we do not guess the filesystem type in the kernel. Why rw/ro should be different ?

Because it's convenient and it is really not hard or messy to implement.

Another, perhaps weak, argument is that mount(8) does not mandate behavior for the case where neither ro or rw are requested (the default is not documented) and that leaves room for the proposed change.

[imp]

In D13361#278954, @avg wrote:

In D13361#278943, @kib wrote:

For instance, we do not guess the filesystem type in the kernel. Why rw/ro should be different ?

Because it's convenient and it is really not hard or messy to implement.

Another, perhaps weak, argument is that mount(8) does not mandate behavior for the case where neither ro or rw are requested (the default is not documented) and that leaves room for the proposed change.

Historic unix behavior is against you. People rely on the current behavior failing when the disk isn't writable to keep them from proceeding in, for example, their scripts. They don't specify rw because that's the default and has been the default behavior since Bell Labs First Edition Unix when the mount command was introduced...

[avg]

I'd rather focus on the convenience of a modern user than on the historic Unix behavior.

Not sure if any of you use a FreeBSD-based desktop environment, I do, KDE.
It's supposed to be one with the most knobs.
Unfortunately, it does not offer a read-only mount button, just mount.
So, if I happen to insert a write-protected SD card, then I cannot mount it through the desktop interface.
Of course, I know how to use the command line. And, of course, it's a deficiency of KDE that it does not offer a readonly mount option and does not automatically detect readonly media, etc.
But if I can make things a little bit better (for myself, first and foremost), I try to do it.

P.S.
And it's a shame that we have VFS / buffer cache bugs like this one https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037#c0 and they do not get fixed for many months (if not years).

[imp]

In D13361#278967, @avg wrote:

I'd rather focus on the convenience of a modern user than on the historic Unix behavior.

I'd rather not break scripts that reply on this behavior. I know of several that exist at prior employers.

It's not a no, but it's push back that this isn't POLA based on what people expect.

And it's a shame that we have VFS / buffer cache bugs like this one https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037#c0 and they do not get fixed for many months (if not years).

We all know there's issues in the buffer cache for a long time. This is but one of many problems there, and it isn't so easy to fix. Every time I've tweaked code in that area, I've discovered I introduced another bug that's not discovered or traced down for months... It's also orthogonal to the current issue at hand... Then again, I've been looking to fund a position that would do nothing but fix the strange panics from the error path of the buffer cache/ufs w/o luck. :(

[avg]

It's not a no, but it's push back that this isn't POLA based on what people expect.

Well, it depends on definition of "people".
I know that one wide-spread OS does this and so some people are used to it.
"mount: block device /dev/sdb1 is write-protected, mounting read-only"
But I am not sure if it does that in kernel or in userland.

[kib]

In D13361#278984, @avg wrote:

It's not a no, but it's push back that this isn't POLA based on what people expect.

Well, it depends on definition of "people".
I know that one wide-spread OS does this and so some people are used to it.
"mount: block device /dev/sdb1 is write-protected, mounting read-only"
But I am not sure if it does that in kernel or in userland.

I might accept this behavior if enabled by a specific mount option. But generally this is quite anti-pattern for Unix, where command does exactly what asked for or fails.

[avg]

just rebase on a newer head

[avg]

• do not allow automatic r/o fallback by default.
• add a new mount option, autoro, to request the fallback.
• provide a new sysctl, vfs.default_autoro, to enable the automatic fallback by default; the fallback is attempted only if none of ro, rw, noro, norw, rdonly is specified.

Maybe autoro and default_autoro are not the best names.
Any suggestions are appreciated.

[cem]

sys/kern/vfs_mount.c

84

Prefer bool for new boolean sysctls, I think.

[cem]

sys/kern/vfs_mount.c

692–697

It does seem like these are not needed or make the fsflags MNT_RDONLY check redundant.

[avg]

document autoro in mount.8

[avg]

use SYSCTL_BOOL for a boolean knob (suggested by @cem)

[avg]

sys/kern/vfs_mount.c

84

I didn't realize that we had SYSCTL_BOOL.
Thanks!

692–697

These are indeed redundant, but I want to have them, so that it is very clear than any explicit option overrides the fallback logic.

[cem]

sys/kern/vfs_mount.c

692–697

Sure, it's harmless.

[avg]

rebase to r331615