On Fri, Jul 10, 2020 at 12:16:09PM +0200, Richard Brown wrote:
In general fstab is still the preferred method for that, see systemd.mount(8). Why deviate from that? I know there is a mount unit file somewhere in the system.
To copy-paste the answer from when the Fedora community discussed this back in 2012:
"We believe that /etc/fstab is the place to configure real file systems, for actual user data, backed by real devices. The API file system /tmp does not qualify for that in our eyes. /tmp is very much something that should just exist as part of the OS and needs no user configuration. It is our goal to allow systems to boot up fully functional with an (almost) empty /etc/fstab. Also it is much easier to enable this logic for existing installs without the need to patch /etc/fstab. This is especially the case since making code that patches /etc/fstab like this idempotent is very hard since the user could just remove the entry we patched in and we couldn't distuingish this case from the not-yet-patched case.
Note that /etc/fstab takes precedence over the systemd unit file. Systems which mount a specific file system to /tmp hence will continue to work as always."
In our case, as /tmp is by default a btrfs subvolume (and so mentioned in the fstab), this actually means my proposed change will not impact existing default systems, unless the consensus that we impliment this change in a way that edits peoples existing fstabs.
That is exactly the problem: YaST does generate an entry for /tmp. So without changing that tmpfs for /tmp will not be used (unless the user disables snapshots or selects a different filesystem for root). With the simple solution of YaST not adding an entry the user has no simply way of disabling tmpfs for /tmp anymore - at least not without the consequence of making snapshots of /tmp which looks very bad to me. The user would have to disable the mount unit, create a snapshot in the right way, and add it to fstab. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org