On Sun, Apr 9, 2017 at 4:58 AM, Deepa Dinamani email@example.com wrote:
Allow read only mounts for filesystems that do not have maximum timestamps beyond the y2038 expiry timestamp.
This option seems arbitrary and pointless.
Nobody sane should ever enable it except for testing, but for testing it would be much better to simply specify what the limit should be: 2038 is not magical for all filesystems, because the base may be different.
Yes, the way the patch is right now, it is meant only for testing y2038 readiness. The feature is meant for system wide tests and not individual filesystem tests.
There is one global option that I want to see, and that is for completely disabling all components that are known to be broken in y2038.
We could do this with just a compile-time option that primarily turns off all drivers using the 32-bit time_t, but the same compile-time option can also force the file system to be read-only.
I don't see this just as something we want to do for testing, but also as a safeguard for people shipping embedded systems with long service life: If something can go wrong after write-mounting an ext3 file system after 2038, it's better to force a behavior now that can be reasonably expected not to change.
Between doing a compile-time option or a boot-time option, doing it purely compile-time is probably better as it gives us the possible additional checking when we hide the time_t definition.
We can do the boot-time option as well, to set a particular limit other than the one enforced at compile time. Passing a year number like "fstimestampcheck=2099" would address Linus' concern about the cutoff being arbitrary.
I would also make the default limit higher than 2038, as at least the Apple HFS/HFS+ file systems break only a bit later in 2040. However, I don't think any other file system breaks until 2099 (some Microsoft file systems), which would be the next reasonably default cutoff IMO.
And honestly, for testing, it would be much better to just make it a mount option rather than some crazy system-wide one.
The patch allows the y2038 number to be changed at compile time. I can extend the sysctl and boot option to allow changing of this limit also if that is preferred.
We also proposed the mount option route in the RFC. But, we received no preferences/ comments. We proceeded with the sysctl option because this allows us to extend this feature into disallowing writes on non updatable time filesystems.
I could change this to providing a mount option instead if you think that is better.
I don't see much value in a mount option that prevents the use, but maybe a mount option to override the global setting to make an exception for someone who does want to mount a particular (known-broken) file system despite having the stricter global setting.