>> 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. The original idea was to disallow writes on all filesystem mounts that were not able to update times at the time of mount, meaning max time supported by the filesystem should be greater than current system time. But, then we end up with the problem of what to do about mounts whose max time exceeds current time after mount. This can be handled by some logic while updating inode times. But, maybe this level of complexity is not required and we could just stick to the former use case. And, just print a warning in the latter case. This is what pushes the feature to be something more than y2038 readiness. > 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. -Deepa
