[opensuse-factory] Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock
Hi all, this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) - /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Frederic Crozat wrote:
- /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
I can see this one causing a few issues, especially for existing users, but at least there is an easy work-around. -- Per Jessen, Zürich (16.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 27/03/12 13:08, Frederic Crozat escribió:
Hi all,
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) - /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
+1000, that makes a lot of sense, thanks for your efforts :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/27/2012 12:08 PM, Frederic Crozat wrote:
Hi all,
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) - /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount. Robert
-- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit :
On 03/27/2012 12:08 PM, Frederic Crozat wrote:
Hi all,
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) - /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
This will need to be tested but I think systemd will just "override" the default from /etc/fstab in that case (but I'm not 100% sure) -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2012-03-27 T 18:46 +0200 Frederic Crozat wrote:
Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit:
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
This will need to be tested but I think systemd will just "override" the default from /etc/fstab in that case (but I'm not 100% sure)
That would be rather inconvenient: think about people who might have special mount options to /tmp on tmpfs, such as size, ... so long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE® Linux Enterprise SUSE LINUX Products GmbH Maxfeldstraße 5 90409 Nürnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 27, 2012 at 07:16:23PM +0200, Matthias G. Eckermann wrote:
On 2012-03-27 T 18:46 +0200 Frederic Crozat wrote:
Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit:
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
This will need to be tested but I think systemd will just "override" the default from /etc/fstab in that case (but I'm not 100% sure)
That would be rather inconvenient: think about people who might have special mount options to /tmp on tmpfs, such as size, ...
We should cover at least these two cases: a) Is /tmp covered by special settings in /etc/fstab? If that's the case we inform the user via a short comment in the syslog and systemd does nothing further regading /tmp If systemd is such a relaxed and flexible dude and allows it. I have my expectations and count on the systemd dictatorship. ;) b) If we're sure this is a system which used the old default method to handle /tmp (by doing nothing special) we move anything from inside /tmp to a speaking new location we created before with the help of mktemp -d /tmp-backup-$( date +%F)-XXXX Else a less experience user might be surprised. On the other had such users also might miss the new location. We also have to ensure such move is only performed one time. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Le mardi 27 mars 2012 à 21:33 +0200, Lars Müller a écrit :
On Tue, Mar 27, 2012 at 07:16:23PM +0200, Matthias G. Eckermann wrote:
On 2012-03-27 T 18:46 +0200 Frederic Crozat wrote:
Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit:
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
This will need to be tested but I think systemd will just "override" the default from /etc/fstab in that case (but I'm not 100% sure)
That would be rather inconvenient: think about people who might have special mount options to /tmp on tmpfs, such as size, ...
We should cover at least these two cases:
a) Is /tmp covered by special settings in /etc/fstab?
If that's the case we inform the user via a short comment in the syslog and systemd does nothing further regading /tmp
If systemd is such a relaxed and flexible dude and allows it. I have my expectations and count on the systemd dictatorship. ;)
to allow that, we would need to either: - drop the dependency (local-fs.target/tmp.mount) and the tmp.mount file from /lib/systemd/system : not really good since they are "on disk" and would be packaged - create a generator checking for /etc/fstab which would create a tmp.mount file in /run/systemd/generator, which would override anything in /lib/systemd/system (stuff in /etc/systemd/system will always have priority: admins have the last word about it).
b) If we're sure this is a system which used the old default method to handle /tmp (by doing nothing special) we move anything from inside /tmp to a speaking new location we created before with the help of
mktemp -d /tmp-backup-$( date +%F)-XXXX
Else a less experience user might be surprised. On the other had such users also might miss the new location.
We also have to ensure such move is only performed one time.
That is a possibility, indeed. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Mar 28, 2012 at 11:35:45AM +0200, Frederic Crozat wrote:
to allow that, we would need to either: - drop the dependency (local-fs.target/tmp.mount) and the tmp.mount file from /lib/systemd/system : not really good since they are "on disk" and would be packaged
It's the job of the integrator to tweak the packages that they work well with the rest of the system. Nowhere is statet that we have to blindly follow upstream. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 11:39 +0200, Michael Schroeder a écrit :
On Wed, Mar 28, 2012 at 11:35:45AM +0200, Frederic Crozat wrote:
to allow that, we would need to either: - drop the dependency (local-fs.target/tmp.mount) and the tmp.mount file from /lib/systemd/system : not really good since they are "on disk" and would be packaged
It's the job of the integrator to tweak the packages that they work well with the rest of the system. Nowhere is statet that we have to blindly follow upstream.
Agreed. But this is where most distributions will be going in the future, I think. I wrote this announce email on purpose, to raise the topic, to get feedback (and unfortunately, flames, because people can't stay on un-emotional technical only discussions on factory, apparently, which is unfortunate) and see what we do about it and which options we should follow. Nothing is set in stone yet. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.03.2012 21:33, schrieb Lars Müller:
b) If we're sure this is a system which used the old default method to handle /tmp (by doing nothing special) we move anything from inside /tmp to a speaking new location we created before with the help of
mktemp -d /tmp-backup-$( date +%F)-XXXX
Else a less experience user might be surprised. On the other had such users also might miss the new location.
This moving of old /tmp/ contents is actually necessary, because otherwise users cannot recover the stuff after the switch: it will become unaccessible (without expert knowledge) since /tmp is overmounted with tmpfs. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried writes:
This moving of old /tmp/ contents is actually necessary, because otherwise users cannot recover the stuff after the switch: it will become unaccessible (without expert knowledge) since /tmp is overmounted with tmpfs.
Reminds me that I still have files hidden this way under /var/run and probably /var/lock... I probably wouldn't have noticed if sudo hadn't forgotten that it had already "lectured" me due to this. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 27 mars 2012 à 19:16 +0200, Matthias G. Eckermann a écrit :
On 2012-03-27 T 18:46 +0200 Frederic Crozat wrote:
Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit:
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
This will need to be tested but I think systemd will just "override" the default from /etc/fstab in that case (but I'm not 100% sure)
That would be rather inconvenient: think about people who might have special mount options to /tmp on tmpfs, such as size, ...
I've done some tests about this particular changes (forward porting the patch to see its effects) : * systemd ships its own tmp.mount file which is overriding any information which might be relevant in /etc/fstab regarding /tmp * however, this file is overridable in /etc/systemd/system (as it was explained in the url I gave regarding this feature on Fedora) : - if we want to disable mounting /tmp as tmpfs, ln -s /dev/null /etc/systemd/system/tmp.mount will be enough (the defaults won't be applied) - if other settings are needed than the one from /lib/systemd/system/tmp.mount, adding options in /etc/systemd/system/tmp.mount will work (and even something like mounting /tmp to a separate partition) - a radical solution could also be to remove file in /lib/systemd/system/tmp.mount and symlink in /lib/systemd/system/local-fs.target/tmp.mount to make sure systemd doesn't take care of /tmp. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 28 Mar 2012, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 19:16 +0200, Matthias G. Eckermann a écrit :
On 2012-03-27 T 18:46 +0200 Frederic Crozat wrote:
Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit:
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
This will need to be tested but I think systemd will just "override" the default from /etc/fstab in that case (but I'm not 100% sure)
That would be rather inconvenient: think about people who might have special mount options to /tmp on tmpfs, such as size, ...
I've done some tests about this particular changes (forward porting the patch to see its effects) : * systemd ships its own tmp.mount file which is overriding any information which might be relevant in /etc/fstab regarding /tmp * however, this file is overridable in /etc/systemd/system (as it was explained in the url I gave regarding this feature on Fedora) : - if we want to disable mounting /tmp as tmpfs, ln -s /dev/null /etc/systemd/system/tmp.mount will be enough (the defaults won't be applied) - if other settings are needed than the one from /lib/systemd/system/tmp.mount, adding options in /etc/systemd/system/tmp.mount will work (and even something like mounting /tmp to a separate partition) - a radical solution could also be to remove file in /lib/systemd/system/tmp.mount and symlink in /lib/systemd/system/local-fs.target/tmp.mount to make sure systemd doesn't take care of /tmp.
This ignorance of systemd of standard configuration files gets annoying ... Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
On Wednesday 28 March 2012, Richard Guenther wrote:
On Wed, 28 Mar 2012, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 19:16 +0200, Matthias G. Eckermann a écrit :
On 2012-03-27 T 18:46 +0200 Frederic Crozat wrote:
Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit:
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
This will need to be tested but I think systemd will just "override" the default from /etc/fstab in that case (but I'm not 100% sure)
That would be rather inconvenient: think about people who might have special mount options to /tmp on tmpfs, such as size, ...
I've done some tests about this particular changes (forward porting the patch to see its effects) : * systemd ships its own tmp.mount file which is overriding any information which might be relevant in /etc/fstab regarding /tmp * however, this file is overridable in /etc/systemd/system (as it was explained in the url I gave regarding this feature on Fedora) : - if we want to disable mounting /tmp as tmpfs, ln -s /dev/null /etc/systemd/system/tmp.mount will be enough (the defaults won't be applied) - if other settings are needed than the one from /lib/systemd/system/tmp.mount, adding options in /etc/systemd/system/tmp.mount will work (and even something like mounting /tmp to a separate partition) - a radical solution could also be to remove file in /lib/systemd/system/tmp.mount and symlink in /lib/systemd/system/local-fs.target/tmp.mount to make sure systemd doesn't take care of /tmp.
This ignorance of systemd of standard configuration files gets annoying ...
Just try to _believe_ like Poettering that all this is good :) https://fedoraproject.org/wiki/Features/tmp-on-tmpfs "Why is this mount established via a systemd unit file, instead of an entry in /etc/fstab?" cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 3/28/2012 6:49 AM, Ruediger Meier wrote:
On Wednesday 28 March 2012, Richard Guenther wrote:
On Wed, 28 Mar 2012, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 19:16 +0200, Matthias G. Eckermann a écrit :
On 2012-03-27 T 18:46 +0200 Frederic Crozat wrote:
Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit:
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
This will need to be tested but I think systemd will just "override" the default from /etc/fstab in that case (but I'm not 100% sure)
That would be rather inconvenient: think about people who might have special mount options to /tmp on tmpfs, such as size, ...
I've done some tests about this particular changes (forward porting the patch to see its effects) : * systemd ships its own tmp.mount file which is overriding any information which might be relevant in /etc/fstab regarding /tmp * however, this file is overridable in /etc/systemd/system (as it was explained in the url I gave regarding this feature on Fedora) : - if we want to disable mounting /tmp as tmpfs, ln -s /dev/null /etc/systemd/system/tmp.mount will be enough (the defaults won't be applied) - if other settings are needed than the one from /lib/systemd/system/tmp.mount, adding options in /etc/systemd/system/tmp.mount will work (and even something like mounting /tmp to a separate partition) - a radical solution could also be to remove file in /lib/systemd/system/tmp.mount and symlink in /lib/systemd/system/local-fs.target/tmp.mount to make sure systemd doesn't take care of /tmp.
This ignorance of systemd of standard configuration files gets annoying ...
Just try to _believe_ like Poettering that all this is good :) https://fedoraproject.org/wiki/Features/tmp-on-tmpfs "Why is this mount established via a systemd unit file, instead of an entry in /etc/fstab?"
How come when _I_ want to do something new and different like, say, store temp stuff on a tempfs, _I_ would _naturally_ do it by adding a NEW directory, /mtmp or /rtmp, etc, and I'd any programs that I knew could get along in a fixed amount of utterly transient space. NOT change the behavior of something as universal and ancient as /tmp itself, break a few common and current and popular apps to use some other location, and let the entire rest of the world of unix-like software break or not break without knowing or caring. Yet when these wacks have the same idea, the only possible way to do it is "everything that this would break, is already broken" Why isn't "improve without destroying" a consideration? /tmp already has an established usage and expected behavior. Something completely new that does not work the way /tmp always did, should go in some new place that can't possibly break anything else. It's conflict-free progress for free in this case. All the special cases like embedded systems where /tmp might be tmpfs, are special cases. those systems by definition do not have to worry about one byte of code other than what the system comes with. All the general purpose systems out there already where the user or admin has gone out of their way to set up /tmp in ram (hey I have some myself) are likewise irrelevant to this discussion. Just because I did that to some server where I either wanted to experiment, or I knew that particular hardware and software combo was ok for it, and it worked out ok, in no way implies it's a sane _default_. Not for a general-purpose OS. Fedora should have no bearing either. If I wanted to run Fedora, I'd run Fedora. The closer Suse gets to Fedora the less reason I have to use Suse. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-30 23:11, Brian K. White wrote:
/tmp already has an established usage and expected behavior. Something completely new that does not work the way /tmp always did, should go in some new place that can't possibly break anything else. It's conflict-free progress for free in this case.
Agreed. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk92I2kACgkQIvFNjefEBxqxGACeKbuWOvAEbuvE+fZZ/4nzSXoU iTQAni3plzAFMvLiK/qO2w4/Uz31jf/7 =oKLG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 12:38 +0200, Richard Guenther a écrit :
This ignorance of systemd of standard configuration files gets annoying ...
It is not an ignorance, but a matter of priority between "native" (ie systemd) and legacy things. Again, nothing is set in stone, upstream might change that (after discussing with them). Another possibility could be that fstab is handled by systemd generator, so there would be no longer a distinction between "native" and non-native. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 27, 2012 at 06:46:23PM +0200, Frederic Crozat wrote:
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
This will need to be tested but I think systemd will just "override" the default from /etc/fstab in that case (but I'm not 100% sure)
I thought we are talking about having /tmp on tmpfs on default (but still allowing admin to change it manually to whatever they want or need) so that I didn't have any problem with that. But now when you are talking about systemd "overriding" /etc/fstab... this is evil. I strongly disagree with anything like that. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-27 19:40, Michal Kubecek wrote:
On Tue, Mar 27, 2012 at 06:46:23PM +0200, Frederic Crozat wrote:
I thought we are talking about having /tmp on tmpfs on default (but still allowing admin to change it manually to whatever they want or need) so that I didn't have any problem with that.
But now when you are talking about systemd "overriding" /etc/fstab... this is evil. I strongly disagree with anything like that.
Indeed. There are people that use a very large partition for /tmp. Some programs needs gigabytes of temporary space. You can not make those people use tmpfs. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yKQ0ACgkQIvFNjefEBxo5vwCgkUEl4Z5E528WTodXe8jc7Zjk tMMAoNAGzPGDaKKdRYk8nieABKBPkWmE =ntPQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 27/03/12 17:54, Carlos E. R. escribió:
There are people that use a very large partition for /tmp. Some programs needs gigabytes of temporary space. You can not make those people use tmpfs.
so what ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-28 01:15, Cristian Rodríguez wrote:
El 27/03/12 17:54, Carlos E. R. escribió:
There are people that use a very large partition for /tmp. Some programs needs gigabytes of temporary space. You can not make those people use tmpfs.
so what ?
Oh, how very nice of you, disregarding he fate of your users. :-( - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yTBMACgkQIvFNjefEBxrKowCfaL6IOBTNwaeyos5+SAXSdCB1 v8wAn03fgyJTVx8bJtX52KbmS4Av+n1T =Lsdw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 27/03/12 20:24, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-28 01:15, Cristian Rodríguez wrote:
El 27/03/12 17:54, Carlos E. R. escribió:
There are people that use a very large partition for /tmp. Some programs needs gigabytes of temporary space. You can not make those people use tmpfs.
so what ?
Oh, how very nice of you, disregarding he fate of your users. :-(
I am not disregarding it, such programs need to use /var/tmp instead. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-28 01:27, Cristian Rodríguez wrote:
El 27/03/12 20:24, Carlos E. R. escribió:
Oh, how very nice of you, disregarding he fate of your users. :-(
I am not disregarding it, such programs need to use /var/tmp instead.
Ok, so you go out and reprogram all the Linux list of programs out there. When they fail, you go and mend them. All of them. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yUzEACgkQIvFNjefEBxp/1wCaA4lMhz4iRxg/FRMgF6OypMg2 QsEAoMob2JWuhUAcU6myhHz4tFLjDX0A =s2gV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 27/03/12 20:54, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-28 01:27, Cristian Rodríguez wrote:
El 27/03/12 20:24, Carlos E. R. escribió:
Oh, how very nice of you, disregarding he fate of your users. :-(
I am not disregarding it, such programs need to use /var/tmp instead.
Ok, so you go out and reprogram all the Linux list of programs out there. When they fail, you go and mend them. All of them.
That's unreasonable, we can only fix programs included in the opensuse distribution. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez (crrodriguez@opensuse.org) wrote:
El 27/03/12 20:54, Carlos E. R. escribió:
On 2012-03-28 01:27, Cristian Rodríguez wrote:
El 27/03/12 20:24, Carlos E. R. escribió:
Oh, how very nice of you, disregarding he fate of your users. :-(
I am not disregarding it, such programs need to use /var/tmp instead.
Ok, so you go out and reprogram all the Linux list of programs out there. When they fail, you go and mend them. All of them.
That's unreasonable, we can only fix programs included in the opensuse distribution.
So any program outside the openSUSE distribution which puts huge files in /tmp become unusable, and most users of those programs are then forced to use another Linux distro. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 10:30 +0100, Adam Spiers a écrit :
Cristian Rodríguez (crrodriguez@opensuse.org) wrote:
El 27/03/12 20:54, Carlos E. R. escribió:
On 2012-03-28 01:27, Cristian Rodríguez wrote:
El 27/03/12 20:24, Carlos E. R. escribió:
Oh, how very nice of you, disregarding he fate of your users. :-(
I am not disregarding it, such programs need to use /var/tmp instead.
Ok, so you go out and reprogram all the Linux list of programs out there. When they fail, you go and mend them. All of them.
That's unreasonable, we can only fix programs included in the opensuse distribution.
So any program outside the openSUSE distribution which puts huge files in /tmp become unusable, and most users of those programs are then forced to use another Linux distro.
Well, Fedora will do a similar switch, so in the future (no idea when, though), programs will be fixed to use /var/tmp when they rely on persistent / huge storage for their own data. And as I wrote in my initial mail, this behavior can be disabled. Currently, we have no data on programs behaviour regarding /tmp, so it is difficult to guess. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 March 2012, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 10:30 +0100, Adam Spiers a écrit :
Cristian Rodríguez (crrodriguez@opensuse.org) wrote:
El 27/03/12 20:54, Carlos E. R. escribió:
On 2012-03-28 01:27, Cristian Rodríguez wrote:
El 27/03/12 20:24, Carlos E. R. escribió:
Oh, how very nice of you, disregarding he fate of your users. :-(
I am not disregarding it, such programs need to use /var/tmp instead.
Ok, so you go out and reprogram all the Linux list of programs out there. When they fail, you go and mend them. All of them.
That's unreasonable, we can only fix programs included in the opensuse distribution.
So any program outside the openSUSE distribution which puts huge files in /tmp become unusable, and most users of those programs are then forced to use another Linux distro.
Well, Fedora will do a similar switch, so in the future (no idea when, though), programs will be fixed to use /var/tmp when they rely on persistent / huge storage for their own data.
/var/tmp is persistent over reboot which is a different use case. Users or programs writing to /tmp are doing this for a good reason until you proof for any particular case that they are doing wrong.
And as I wrote in my initial mail, this behavior can be disabled.
Why can't it be enabled keeping the current behaviour per default?
Currently, we have no data on programs behaviour regarding /tmp, so it is difficult to guess.
Please consider also the user behaviour. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 11:10 +0100, Ruediger Meier a écrit :
On Wednesday 28 March 2012, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 10:30 +0100, Adam Spiers a écrit :
Cristian Rodríguez (crrodriguez@opensuse.org) wrote:
El 27/03/12 20:54, Carlos E. R. escribió:
On 2012-03-28 01:27, Cristian Rodríguez wrote:
El 27/03/12 20:24, Carlos E. R. escribió: >Oh, how very nice of you, disregarding he fate of your users. > :-(
I am not disregarding it, such programs need to use /var/tmp instead.
Ok, so you go out and reprogram all the Linux list of programs out there. When they fail, you go and mend them. All of them.
That's unreasonable, we can only fix programs included in the opensuse distribution.
So any program outside the openSUSE distribution which puts huge files in /tmp become unusable, and most users of those programs are then forced to use another Linux distro.
Well, Fedora will do a similar switch, so in the future (no idea when, though), programs will be fixed to use /var/tmp when they rely on persistent / huge storage for their own data.
/var/tmp is persistent over reboot which is a different use case. Users or programs writing to /tmp are doing this for a good reason until you proof for any particular case that they are doing wrong.
And as I wrote in my initial mail, this behavior can be disabled.
Why can't it be enabled keeping the current behaviour per default?
Because I wanted feedback, based on facts (and not just reaction to changes, like some people seem to do). So far, we have some feedback, but as Takashi noted, we don't have test results to see if it is really a problem or not.
Currently, we have no data on programs behaviour regarding /tmp, so it is difficult to guess.
Please consider also the user behaviour.
I think it is easier to educate users than patch closed-source programs ;) -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 March 2012, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 11:10 +0100, Ruediger Meier a écrit :
On Wednesday 28 March 2012, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 10:30 +0100, Adam Spiers a écrit :
Cristian Rodríguez (crrodriguez@opensuse.org) wrote:
El 27/03/12 20:54, Carlos E. R. escribió:
On 2012-03-28 01:27, Cristian Rodríguez wrote: >El 27/03/12 20:24, Carlos E. R. escribió: >>Oh, how very nice of you, disregarding he fate of your >> users. >> >> :-( > >I am not disregarding it, such programs need to use > /var/tmp instead.
Ok, so you go out and reprogram all the Linux list of programs out there. When they fail, you go and mend them. All of them.
That's unreasonable, we can only fix programs included in the opensuse distribution.
So any program outside the openSUSE distribution which puts huge files in /tmp become unusable, and most users of those programs are then forced to use another Linux distro.
Well, Fedora will do a similar switch, so in the future (no idea when, though), programs will be fixed to use /var/tmp when they rely on persistent / huge storage for their own data.
/var/tmp is persistent over reboot which is a different use case. Users or programs writing to /tmp are doing this for a good reason until you proof for any particular case that they are doing wrong.
And as I wrote in my initial mail, this behavior can be disabled.
Why can't it be enabled keeping the current behaviour per default?
Because I wanted feedback, based on facts (and not just reaction to changes, like some people seem to do).
So far, we have some feedback, but as Takashi noted, we don't have test results to see if it is really a problem or not.
Currently, we have no data on programs behaviour regarding /tmp, so it is difficult to guess.
Please consider also the user behaviour.
I think it is easier to educate users than patch closed-source programs ;)
Yep, I've educated my users to use the fast,local /tmp or /var/tmp whenever it's possible rather than the expensive NFS homes. I'm happy to see they are doing it right now. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/28/2012 07:10 AM, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 11:10 +0100, Ruediger Meier a écrit :
On Wednesday 28 March 2012, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 10:30 +0100, Adam Spiers a écrit :
Cristian Rodríguez (crrodriguez@opensuse.org) wrote:
El 27/03/12 20:54, Carlos E. R. escribió:
On 2012-03-28 01:27, Cristian Rodríguez wrote: > El 27/03/12 20:24, Carlos E. R. escribió: >> Oh, how very nice of you, disregarding he fate of your users. >> :-( > > I am not disregarding it, such programs need to use /var/tmp > instead.
Ok, so you go out and reprogram all the Linux list of programs out there. When they fail, you go and mend them. All of them.
That's unreasonable, we can only fix programs included in the opensuse distribution.
So any program outside the openSUSE distribution which puts huge files in /tmp become unusable, and most users of those programs are then forced to use another Linux distro.
Well, Fedora will do a similar switch, so in the future (no idea when, though), programs will be fixed to use /var/tmp when they rely on persistent / huge storage for their own data.
/var/tmp is persistent over reboot which is a different use case. Users or programs writing to /tmp are doing this for a good reason until you proof for any particular case that they are doing wrong.
And as I wrote in my initial mail, this behavior can be disabled.
Why can't it be enabled keeping the current behaviour per default?
Because I wanted feedback, based on facts (and not just reaction to changes, like some people seem to do).
I know of one Finite Element code base that uses $TMPDIR to write large temporary files. These files my exceed 10GB. Thus mounting /tmp as tmpfs and having $TMPDIR point to /tmp is not a good solution for this use case. Other solutions in this area of HPC probably behave in a similar fashion. Sysadmins for systems that are setup to run this code would have to do extra work compared to today's install/setup. Basically a +1 to the use case Richard described with gcc. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 27 March 2012 20:27:21 Cristian Rodríguez wrote:
El 27/03/12 20:24, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-28 01:15, Cristian Rodríguez wrote:
El 27/03/12 17:54, Carlos E. R. escribió:
There are people that use a very large partition for /tmp. Some programs needs gigabytes of temporary space. You can not make those people use tmpfs.>> so what ?
Oh, how very nice of you, disregarding he fate of your users. :-(
I am not disregarding it, such programs need to use /var/tmp instead. I thought that was for non-volatile cache? /tmp would be for stuff which can be wiped on a system reboot, yes? Nothing is said about size of that place, right?
On 03/27/2012 02:54 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-27 19:40, Michal Kubecek wrote:
On Tue, Mar 27, 2012 at 06:46:23PM +0200, Frederic Crozat wrote: I thought we are talking about having /tmp on tmpfs on default (but still allowing admin to change it manually to whatever they want or need) so that I didn't have any problem with that.
But now when you are talking about systemd "overriding" /etc/fstab... this is evil. I strongly disagree with anything like that. Indeed.
There are people that use a very large partition for /tmp. Some programs needs gigabytes of temporary space. You can not make those people use tmpfs.
- -- Cheers / Saludos,
Pro/E and Maya pop into mind where this could cause an issue. Dean Hilkewich -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 27 mars 2012 à 18:51 -0600, Dean Hilkewich a écrit :
On 03/27/2012 02:54 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-27 19:40, Michal Kubecek wrote:
On Tue, Mar 27, 2012 at 06:46:23PM +0200, Frederic Crozat wrote: I thought we are talking about having /tmp on tmpfs on default (but still allowing admin to change it manually to whatever they want or need) so that I didn't have any problem with that.
But now when you are talking about systemd "overriding" /etc/fstab... this is evil. I strongly disagree with anything like that. Indeed.
There are people that use a very large partition for /tmp. Some programs needs gigabytes of temporary space. You can not make those people use tmpfs.
- -- Cheers / Saludos,
Pro/E and Maya pop into mind where this could cause an issue.
Are they following just /tmp or TMPDIR ? If you can test those, it would be interested to have informations. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 27/03/12 13:35, Robert Schweikert escribió:
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
Robert
Other than the "is already mounted in..." warning, I do not see other ugly side effect it might have... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 27 March 2012 18.08:01 Frederic Crozat wrote:
Hi all,
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices okay so all work and effort to fix situation comparing 11.4 and 12.1 is lost (again :-() but /run/media/<user> Sometimes (old song) they should really think about that not all computers are phone device. We will adapt again to survive - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. How much package will have to be fixed again just for that ? We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) Could it be pushed before M3 please to have a better timeframe for feedback and tests? - /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users. Just have a clear listing of all application that need to be fixed and all kind of usage verified, like split tar gimp inkscape (memory hungry things) etc and all kind of stuff that could use /tmp There's a bunch of application that use it to swap undo and kind of things using tmpfs could be pretty counter intuitive So test and bench need to be written for openQA
the whole /etc/sysconfig/cron has to be revisited completely And a point that need to be clear and have a hook permitting users to clean it up What happens with my old /tmp directory as soon as this feature is enabled? On the next boot we'll simply mount the directory over with a tmpfs. and then you keep forever the 4GB iso you put it inside before the update/upgrade -> move previous /tmp to /tmp.old or rpmsave or whatever than joe and jane can cleanup
Thanks for the RFC Fredirc :D
-- Frederic Crozat <fcrozat@suse.com> SUSE
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 27, 2012 at 3:39 PM, Bruno Friedmann <bruno@ioda-net.ch> wrote:
And a point that need to be clear and have a hook permitting users to clean it up What happens with my old /tmp directory as soon as this feature is enabled? On the next boot we'll simply mount the directory over with a tmpfs.
IIRC, you can't mount on a non-empty directory. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 27, 2012 at 03:48:30PM -0300, Claudio Freire wrote:
On Tue, Mar 27, 2012 at 3:39 PM, Bruno Friedmann <bruno@ioda-net.ch> wrote:
And a point that need to be clear and have a hook permitting users to clean it up What happens with my old /tmp directory as soon as this feature is enabled? On the next boot we'll simply mount the directory over with a tmpfs.
IIRC, you can't mount on a non-empty directory.
You can. I'm even not sure if it was ever impossible. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/3/27 Michal Kubecek <mkubecek@suse.cz>:
IIRC, you can't mount on a non-empty directory.
You can. I'm even not sure if it was ever impossible.
It was, I remember it failing when I wanted to mount loop devices back in 8.x (2.4 kernel), though I bet it was the user space tool the one complaining not the kernel. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 27 mars 2012 à 20:39 +0200, Bruno Friedmann a écrit :
On Tuesday 27 March 2012 18.08:01 Frederic Crozat wrote:
Hi all,
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices okay so all work and effort to fix situation comparing 11.4 and 12.1 is lost (again :-()
There seems to be a general misunderstanding about /media : this particular directory was created to store mounts points created automatically by daemons like hal (in the early days) or udisks / udisks2 (these days), not to store "persistent" mounts points (/mnt is better suited for this). This is why /media was tmpfs-ified with systemd.
- /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. First, I did a mistake in my mail: /var/lock and /var/run were not bind mounted to /run, they were mounted to separate tmpfs.
How much package will have to be fixed again just for that ?
None, if they were already fixed properly for 12.1, where those were already non persistent.
We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) Could it be pushed before M3 please to have a better timeframe for feedback and tests?
We can't push it before the change is available in systemd (otherwise systemd would try to mount over a symlink, which is not possible)
- /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users. Just have a clear listing of all application that need to be fixed and all kind of usage verified, like split tar gimp inkscape (memory hungry things) etc and all kind of stuff that could use /tmp There's a bunch of application that use it to swap undo and kind of things using tmpfs could be pretty counter intuitive So test and bench need to be written for openQA
the whole /etc/sysconfig/cron has to be revisited completely
Well, it already need to be revisited and I'm willing to review patches against systemd-tmpfiles to have handling similar to what was in previous openSUSE release (bnc 721682) but so far, I got nothing..
And a point that need to be clear and have a hook permitting users to clean it up What happens with my old /tmp directory as soon as this feature is enabled?
On the next boot we'll simply mount the directory over with a tmpfs. and then you keep forever the 4GB iso you put it inside before the update/upgrade -> move previous /tmp to /tmp.old or rpmsave or whatever than joe and jane can cleanup
Lars suggested we could do a one time move for the data to a different directory (and maybe even drop a README in the new tmpfs "where are my data done"). -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/27/2012 06:08 PM, Frederic Crozat wrote:
- /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
This will break a ton of boxes. * People won't be able to hibernate because their memory will be full of temp undroppable bloat. * The overall system performance will be *hugely* reduced. Again, because the memory will be full of temp bloat, not having memory for gluttonous firefox. Yes, I still have a notebook with 2G of memory. I still have a 386 box with 512M of memory. And both are currently on the edge. No, thanks, I really don't want any more swapping. Did they think about this change thoroughly? (And yes, I have /tmp as tmpfs on my 6G-of-RAM machine.) BTW stateless /tmp can be achieved by rm -rf /tmp/* at each boot. regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPcjWgAAoJEL0lsQQGtHBJ4UoP/3+GAc8xA9yyFbDORaA0z8hp 8JS16e9eG78M9+h0xN7Xyss/sZNm6SU/0R4jyKRqSlDVIt7Vjzsvc2GnwbWWWfrb 1ltY//wP7f4aGO2cRD4cTekIXpg3/NxydJmSD+LPS7J70jYiCEjNsqYA1BwKmbKW z3bvHtCbH6zLs5atVomx8ec6nerUGtBaGor53NNbpCN54qfB91YbcvanN2Ajkrwk JOm5XvGe80uqKu3ovQLLAMERDedGO4weGReMrJZgeGDOLcb5JHIx5Fji+npIZvIN Xh05EI6vJ6tQNRDf4Sz1+25aofuKyNOn6V2cD5SN6ZbwQQlJ37cFserZkkbYPQFg o4cJXO1+hkuQRgNYCsP7Dmg0UA+Mbv2H+y6O1amnnzPYOS4ZxoleYvhM/Q7P4+cM rRh4G5YxMHcckpyDZpBjmAQvXvfm2FzAj6cqcTGxZjWIwXky++2uO+TehNrbWWxE K4647sB5RNgMnlotCmxZpbuD+7P6fQuQq5U7tMxXmqm6FVMz7ZK9T1QhmSBSZjIW cHuO+lMhzmSs82J/gV5K/g5fngpee4VxVpLCrPcK4yZ4HtaOt7QBiimWS8r+8I8G 3nX1thL7p617ntaDZIxCVgEj3uL8a3baUjcTqkkJ0sbNwu53I3I6UiYCRMJ9wxxc /3ES172z1mzVA2n6qWit =3IPP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 27, 2012 at 6:48 PM, Jiri Slaby <jslaby@suse.cz> wrote:
Yes, I still have a notebook with 2G of memory. I still have a 386 box with 512M of memory. And both are currently on the edge. No, thanks, I really don't want any more swapping.
Did they think about this change thoroughly?
(And yes, I have /tmp as tmpfs on my 6G-of-RAM machine.)
BTW stateless /tmp can be achieved by rm -rf /tmp/* at each boot.
A more important matter is... how does the distribution guarantee correct behavior on low-memory systems? If I install it on a 128M system, you simply can't assume any significant amount of tmpfs storage. What then? Suck up 64M of RAM for tmpfs? That's quite useless for temp files and quite detrimental of system performance. I think this default has to be handled done a lot smarter than "tmpfs by default on all". Remember, 128M is not necessarily a 20-yo box. It may be a virtual machine. Even though you'd expect the need of customization on a VM already, I still think /tmp has to be made really small on all systems (no matter how much RAM), if only to guarantee consistent behavior across all installations. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 27/03/12 19:04, Claudio Freire escribió:
On Tue, Mar 27, 2012 at 6:48 PM, Jiri Slaby<jslaby@suse.cz> wrote:
Yes, I still have a notebook with 2G of memory. I still have a 386 box with 512M of memory. And both are currently on the edge. No, thanks, I really don't want any more swapping.
Did they think about this change thoroughly?
(And yes, I have /tmp as tmpfs on my 6G-of-RAM machine.)
BTW stateless /tmp can be achieved by rm -rf /tmp/* at each boot.
A more important matter is... how does the distribution guarantee correct behavior on low-memory systems?
You can use more swap, and zcache (if it worked with our current kernels, unfortunately it does not) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 27, 2012 at 8:20 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
(And yes, I have /tmp as tmpfs on my 6G-of-RAM machine.)
BTW stateless /tmp can be achieved by rm -rf /tmp/* at each boot.
A more important matter is... how does the distribution guarantee correct behavior on low-memory systems?
You can use more swap, and zcache (if it worked with our current kernels, unfortunately it does not)
You're missing the point. Even if users have the choice to explicitly override this, the defaults on a distribution should be sensible and able to run on the largest base possible. Many server setups explicitly avoid swap because of the performance impact it entails, many regular users do that too, and many programs misbehave in the sense that they write massive amounts of data in /tmp. In low memory devices, with /tmp as tmpfs, think 1G, brasero, k3b and a few other programs, in their default configuration, would thrash. Those are blatantly wrong cases. But there are numerous gray cases. Python's tempfile module creates, by default, files in /tmp. I would bet tons of python apps, thus, misuse /tmp. You *have* to make /tmp small in that case, to make sure those programs break, and to make sure those programs don't eat available RAM. It's the only way to forcibly fix them. Otherwise, testers won't be able to test unless they install on a VM with 128M of RAM. And this is assuming users can override this decision and use a regular filesystem as /tmp. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 27 mars 2012 à 20:27 -0300, Claudio Freire a écrit :
In low memory devices, with /tmp as tmpfs, think 1G, brasero, k3b and a few other programs, in their default configuration, would thrash. Those are blatantly wrong cases. But there are numerous gray cases. Python's tempfile module creates, by default, files in /tmp. I would bet tons of python apps, thus, misuse /tmp.
We should fix those "known" programs to use /var/tmp instead of /tmp anyway.
And this is assuming users can override this decision and use a regular filesystem as /tmp.
As I wrote in my initial email (but few people read it completely apparently), it is possible.. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 March 2012, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 20:27 -0300, Claudio Freire a écrit :
In low memory devices, with /tmp as tmpfs, think 1G, brasero, k3b and a few other programs, in their default configuration, would thrash. Those are blatantly wrong cases. But there are numerous gray cases. Python's tempfile module creates, by default, files in /tmp. I would bet tons of python apps, thus, misuse /tmp.
We should fix those "known" programs to use /var/tmp instead of /tmp anyway.
No, data which is not needed after reboot is wrong in /var/tmp. It's the decision of the data producer where to put it. Keep in mind that anyone who is writing to /tmp is doing this for a good reason. What you are trying to "fix" is "don't use /tmp because it's unusable now".
And this is assuming users can override this decision and use a regular filesystem as /tmp.
As I wrote in my initial email (but few people read it completely apparently), it is possible..
-- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Wed, 28 Mar 2012 11:54:53 +0200, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 20:27 -0300, Claudio Freire a écrit :
In low memory devices, with /tmp as tmpfs, think 1G, brasero, k3b and a few other programs, in their default configuration, would thrash. Those are blatantly wrong cases. But there are numerous gray cases. Python's tempfile module creates, by default, files in /tmp. I would bet tons of python apps, thus, misuse /tmp.
We should fix those "known" programs to use /var/tmp instead of /tmp anyway.
Notorious acroread and flashplayer are such "known" programs, too. IIRC, flashplayer may store a temporary FLV file in /tmp, which can be unlimitedly big. Honestly, someone needs to test carefully (e.g. on a machine with small RAM) before moving toward this direction as default. Only facts and proofs can shut up bike-shed talks. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 12:48 +0200, Takashi Iwai a écrit :
At Wed, 28 Mar 2012 11:54:53 +0200, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 20:27 -0300, Claudio Freire a écrit :
In low memory devices, with /tmp as tmpfs, think 1G, brasero, k3b and a few other programs, in their default configuration, would thrash. Those are blatantly wrong cases. But there are numerous gray cases. Python's tempfile module creates, by default, files in /tmp. I would bet tons of python apps, thus, misuse /tmp.
We should fix those "known" programs to use /var/tmp instead of /tmp anyway.
Notorious acroread and flashplayer are such "known" programs, too. IIRC, flashplayer may store a temporary FLV file in /tmp, which can be unlimitedly big.
Do they hardcode /tmp or use TMPDIR ? That would be interesting to know.
Honestly, someone needs to test carefully (e.g. on a machine with small RAM) before moving toward this direction as default. Only facts and proofs can shut up bike-shed talks.
Agreed. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/28/2012 01:04 PM, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 12:48 +0200, Takashi Iwai a écrit :
At Wed, 28 Mar 2012 11:54:53 +0200, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 20:27 -0300, Claudio Freire a écrit :
In low memory devices, with /tmp as tmpfs, think 1G, brasero, k3b and a few other programs, in their default configuration, would thrash. Those are blatantly wrong cases. But there are numerous gray cases. Python's tempfile module creates, by default, files in /tmp. I would bet tons of python apps, thus, misuse /tmp.
We should fix those "known" programs to use /var/tmp instead of /tmp anyway.
Notorious acroread and flashplayer are such "known" programs, too. IIRC, flashplayer may store a temporary FLV file in /tmp, which can be unlimitedly big.
Do they hardcode /tmp or use TMPDIR ? That would be interesting to know.
Running strings on /usr/lib64/browser-plugins/libflashplayer.so I found no match for TMPDIR but these: /tmp/putH /tmp/FlaH /tmp/FlaH /tmp/crl A readelf -s shows that the library uses mkstemp - where the developers needs to supply a path.
Honestly, someone needs to test carefully (e.g. on a machine with small RAM) before moving toward this direction as default. Only facts and proofs can shut up bike-shed talks.
Agreed.
I propose to collect the options and questions we have at one place in the wiki, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 13:15 +0200, Andreas Jaeger a écrit :
On 03/28/2012 01:04 PM, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 12:48 +0200, Takashi Iwai a écrit :
At Wed, 28 Mar 2012 11:54:53 +0200, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 20:27 -0300, Claudio Freire a écrit :
In low memory devices, with /tmp as tmpfs, think 1G, brasero, k3b and a few other programs, in their default configuration, would thrash. Those are blatantly wrong cases. But there are numerous gray cases. Python's tempfile module creates, by default, files in /tmp. I would bet tons of python apps, thus, misuse /tmp.
We should fix those "known" programs to use /var/tmp instead of /tmp anyway.
Notorious acroread and flashplayer are such "known" programs, too. IIRC, flashplayer may store a temporary FLV file in /tmp, which can be unlimitedly big.
Do they hardcode /tmp or use TMPDIR ? That would be interesting to know.
Running strings on /usr/lib64/browser-plugins/libflashplayer.so I found no match for TMPDIR but these: /tmp/putH /tmp/FlaH /tmp/FlaH /tmp/crl
A readelf -s shows that the library uses mkstemp - where the developers needs to supply a path.
Honestly, someone needs to test carefully (e.g. on a machine with small RAM) before moving toward this direction as default. Only facts and proofs can shut up bike-shed talks.
Agreed.
I propose to collect the options and questions we have at one place in the wiki,
I've created a blank page for now on http://en.opensuse.org/Tmp-on-tmpfs I'll try to fill it with the various informations I got here and from Debian and Gentoo folks. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Mar 28, 2012 at 12:11 PM, Frederic Crozat <fcrozat@suse.com> wrote:
Honestly, someone needs to test carefully (e.g. on a machine with small RAM) before moving toward this direction as default. Only facts and proofs can shut up bike-shed talks.
Agreed.
I propose to collect the options and questions we have at one place in the wiki,
I've created a blank page for now on http://en.opensuse.org/Tmp-on-tmpfs
I'll try to fill it with the various informations I got here and from Debian and Gentoo folks.
I've been using debian testing on a 4G system. I updated from debian squeeze (which used a regular tmp partition) to debian testing (which uses tmpfs). I use memory-intensive programs I write myself - I know their memory usage quite a lot, and I feel the wasted RAM by tmpfs. At first I didn't know why my programs swapped when they didn't use to (they use close to 4G), and then I noticed debian is assigning ~700M to tmpfs. It's hurting even though the partition itself only has 500k used (measured with du --max-depth=0 -h), probably because it will partially fill up during the workload, otherwise I cannot explain the performance difference. And, if you were wondering, it is shadowing an explicit tmp partition I made during installation, but it's not using systemd. So, at least without systemd, debian is not honoring fstab entries. Hope that bit of information is useful. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/28/2012 01:04 PM, Frederic Crozat wrote:
Do they hardcode /tmp or use TMPDIR ?
Is the plan to change TMPDIR? (It would make having /tmp pointless.)
Honestly, someone needs to test carefully (e.g. on a machine with small RAM) before moving toward this direction as default. Only facts and proofs can shut up bike-shed talks.
Agreed.
Yes, agreed. That's why I asked if they had considered this. thanks, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPcxBdAAoJEL0lsQQGtHBJrV4P+gPtndAtLz3xGtL3On1jaCWV Y31/krbDueL3p2dQyBA/DstCXOpODznv15PzIUd/jhLFUZ1oPggTCXYvE3WULpan 1Kn+OUdy2//XuXwpC59cwOgLV/S64/OWvhP4elF5OujwpJq7mJY5MUpadgny9SKu Y+kWTFGf+lyYg61z+Pq/CsKb8rv8eiG37iM6Mvk6VpmLm1uSYgTZrPYDr87fTCKu hufzS3L4nRqqVZchCf81iWiZhrjQ/naMPgOLJ4Ak2msVYLlheYnU4J7Rd+TZAbL8 wdlSfZxtgjPYTHN4IwVtJciGWNY7cwxkVfbY8QjVL2gX1+SbWuDUXEY6UNFrQj9p 8Kbvlhqi2XQSN0fUEwzGshV33av++tIio7lSlxNhyaUi20vUclLCeThMFnONXrBe kXU59APbrCMTKNGRU4//CnwibmE2KEy+URJfX10VAHI09d994+K8oLtUPDJth1aO G4LS3lZtT41R+pPaipbP1IuQrVdozJO6InYEn6bxqIQYadC0maezMP85x/3jtiOe SlkVs3SwSE2PRpa/C+i4oWw2LyXIKbthw/TCqlxycLlSU2DACORVp/2WKVzooGCf JO0OIxU1DG4gayJ0TvSuFtUdVK/3IjVrZYwGc24JyN9PdDvXx/OZ8ts7eNJY7HU+ uw5OJuGLmee+DEuKHl2z =Rk0Z -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 15:21 +0200, Jiri Slaby a écrit :
On 03/28/2012 01:04 PM, Frederic Crozat wrote:
Do they hardcode /tmp or use TMPDIR ?
Is the plan to change TMPDIR? (It would make having /tmp pointless.)
First, I repeat : there is no "plan". I'm announcing things which will change in systemd "upstream". This is outside the scope of systemd, so it would be a decision on our side. See also lnussel suggestion on switching to "user $TMPDIR"
Honestly, someone needs to test carefully (e.g. on a machine with small RAM) before moving toward this direction as default. Only facts and proofs can shut up bike-shed talks.
Agreed.
Yes, agreed. That's why I asked if they had considered this.
The feature has just been opened on Fedora for version 18. And Debian already did the switch some months ago (unrelated to systemd). -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2012-03-28 at 11:54 +0200, Frederic Crozat wrote:
In low memory devices, with /tmp as tmpfs, think 1G, brasero, k3b and a few other programs, in their default configuration, would thrash. Those are blatantly wrong cases. But there are numerous gray cases. Python's tempfile module creates, by default, files in /tmp. I would bet tons of python apps, thus, misuse /tmp.
We should fix those "known" programs to use /var/tmp instead of /tmp anyway.
That's not viable. What about the unknown (at this time) programs? There are closed source programs, too. Or old software. Users would have to back the oS version. Any big change done to Linux will break things beyond your/our control. Please don't.
And this is assuming users can override this decision and use a regular filesystem as /tmp.
As I wrote in my initial email (but few people read it completely apparently), it is possible..
Then this setting should be made at installation time, in Yast. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk91shYACgkQtTMYHG2NR9UAvgCfWnDbGVbgS54YlcwxCUsior+4 T4kAn25pqkLqKeFGTZe+tj9e2EtZmHLs =KN51 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We should fix those "known" programs to use /var/tmp instead of /tmp anyway.
That's not viable. What about the unknown (at this time) programs? There are closed source programs, too. Or old software. Users would have to back the oS version.
Any big change done to Linux will break things beyond your/our control. Please don't.
You know beforehand the answer going to be "we cannot fix and cannot care for what's not in the distribution". - -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk91uhAACgkQCs1dsHJ/X7DzLgCg5mewztznSDSvYIxBpd1M6wAr lv0Ani1QSXIuRWCZJ4Ty9+qnsP9gAUa5 =LroJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 30 March 2012, Ralf Lang wrote:
We should fix those "known" programs to use /var/tmp instead of /tmp anyway.
That's not viable. What about the unknown (at this time) programs? There are closed source programs, too. Or old software. Users would have to back the oS version.
Any big change done to Linux will break things beyond your/our control. Please don't.
You know beforehand the answer going to be "we cannot fix and cannot care for what's not in the distribution".
Err ... we can't fix the unknown - true. That's why we should not break it for no reason. A user who is actively using his /tmp since 15 years without probs is BTW something what we should care about. What is wrong with simply NOT mounting tmpfs on his /tmp per default? cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Can we all please focus on collecting all the pros and cons in the wiki? Else we'll see this type of discussion again and again and don't bring the issue one littel step forward. To any of you: this doesn't say anything about the direction to go. Also the systemd documentation must be consolidated. Even this has to be added to the cons. And this is a task also those of you can address which again and again claim they're not able to contribute code. Thanks, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-30 17:24, Lars Müller wrote:
Can we all please focus on collecting all the pros and cons in the wiki?
Cons: impossible to make sure that _all_ software will work properly if tmp is moved to tmpfs.
Also the systemd documentation must be consolidated. Even this has to be added to the cons. And this is a task also those of you can address which again and again claim they're not able to contribute code.
I'd gladly contribute documentation, but I know my limits. I can not document something I know next to nothing about. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk92IvkACgkQIvFNjefEBxo25ACgzSZSFfngzB7zF6LDyfM8hODy DqAAnj0shTUzHGYrXFWfLK1IXALaJ1rq =q+4X -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 30 Mar 2012 23:17:45 Carlos E. R. wrote:
Cons: impossible to make sure that all software will work properly if tmp is moved to tmpfs.
This is such a broken argument because what you just said can equally be applied to any new Kernel, or any new glibc and so on and so on... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2012-04-01 at 18:27 +0200, Graham Anderson wrote:
On Friday 30 Mar 2012 23:17:45 Carlos E. R. wrote:
Cons: impossible to make sure that all software will work properly if tmp is moved to tmpfs.
This is such a broken argument because what you just said can equally be applied to any new Kernel, or any new glibc and so on and so on...
Which does not happen. I have binaries running that were built 10 years ago. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk94tdEACgkQtTMYHG2NR9UeDQCfS2ifEk0rtamOSgYN4Q9j0Si6 S6UAnitOmLhgYwJvPM+q9qCWLjpve7O1 =MG7e -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 01 Apr 2012 22:08:38 Carlos E. R. wrote:
Which does not happen. I have binaries running that were built 10 years ago.
Eh? it happens all the time... My point is, that using a newer kernel or glibc or [insert system or package version here] can and mostly likely will break some software that someone uses somewhere. Should that prevent us from upgrading our kernel or packages? Of course not, that would be silly. The same argument can be applied to other changes in the system. You are arguing we should not make system changes because some software (that we don't yet know about) might break and I'm telling you that's an impractical and broken argument. Software will _always_ break during a development process. It's simply impossible to prevent; and to use that as an argument against change doesn't make any sense. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/04/12 22:46, Graham Anderson wrote:
The same argument can be applied to other changes in the system. You are arguing we should not make system changes because some software (that we don't yet know about) might break and I'm telling you that's an impractical and broken argument.
Exactly, the number of usecases would then increase exponentially and becomes unmanageable. In this case, the most likely way to go is providing separate tmp directory per-user using pam_namespace(8) , however what kind of storage will be used is still a matter that needs analysis.
Software will _always_ break during a development process. It's simply impossible to prevent; and to use that as an argument against change doesn't make any sense.
Yes, bugs are in the same category of death and taxes :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 3/30/2012 9:50 AM, Ralf Lang wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We should fix those "known" programs to use /var/tmp instead of /tmp anyway.
That's not viable. What about the unknown (at this time) programs? There are closed source programs, too. Or old software. Users would have to back the oS version.
Any big change done to Linux will break things beyond your/our control. Please don't.
You know beforehand the answer going to be "we cannot fix and cannot care for what's not in the distribution".
Indeed. And what a useless distribution it would be if it didn't attempt to be useful for anything that didn't come on the dvd. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 27, 2012 at 8:20 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
You can use more swap, and zcache (if it worked with our current kernels, unfortunately it does not)
And, let me add, that a swapping tmpfs is orders of magnitude (tens of times) slower than a regular file system. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Why not just make it configurable (/etc/sysconfig/something) with a sane default? -- Jon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 27, 2012 at 10:43 PM, Jon Nelson <jnelson-suse@jamponi.net> wrote:
Why not just make it configurable (/etc/sysconfig/something) with a sane default?
I'm giving for granted the fact that it will be. If it is not, then it's simply unacceptable. But, even configurable, the defaults are important, they're what most users will use. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 27/03/12 22:43, Jon Nelson escribió:
Why not just make it configurable (/etc/sysconfig/something) with a sane default?
"/etc/sysconfig" and "sane" do not go in the same sentence, however I do agree that if an fstab entry exists for /tmp it should take precedence. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
however I do agree that if an fstab entry exists for /tmp it should take precedence.
This was a major discussion point before in this thread. I agree, fstab should have the last word. Shipping tmpfs where no fstab for /tmp/ exists seems ok to me. But it should be possible to disable this without having to rebind some part of the dir tree just "to have it in fstab" Please, all, save our mailboxes from yet another systemd-style discussion. - -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9ytpEACgkQCs1dsHJ/X7BVZgCguWfZy4StJeKs5lxfJ3C3gjWe KI0An0GTBBWx7TZKAMmK9710NP1Ex8HB =/f/S -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 27 mars 2012 à 22:48 -0300, Cristian Rodríguez a écrit :
El 27/03/12 22:43, Jon Nelson escribió:
Why not just make it configurable (/etc/sysconfig/something) with a sane default?
"/etc/sysconfig" and "sane" do not go in the same sentence, however I do agree that if an fstab entry exists for /tmp it should take precedence.
See my reply to Matthias. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-28 03:43, Jon Nelson wrote:
Why not just make it configurable (/etc/sysconfig/something) with a sane default?
If the choice is ours, to use tmpfs or not, then yes. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk9ybd4ACgkQIvFNjefEBxp3ngCgpHd+T3sMTELeDHulufFYNvWZ pRUAnRCGTjFzz8hWOl6KaVW3ULBvyHpH =KKPC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 27 mars 2012 à 22:39 -0300, Claudio Freire a écrit :
On Tue, Mar 27, 2012 at 8:20 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
You can use more swap, and zcache (if it worked with our current kernels, unfortunately it does not)
And, let me add, that a swapping tmpfs is orders of magnitude (tens of times) slower than a regular file system.
Debian is using some "default" for tmpfs /tmp to make sure it doesn't eat all memory. See http://lists.debian.org/debian-user/2012/03/msg01713.html -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 27, 2012 at 11:48:16PM +0200, Jiri Slaby wrote:
On 03/27/2012 06:08 PM, Frederic Crozat wrote:
- /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
This will break a ton of boxes. ... Did they think about this change thoroughly?
I doubt it - but only because it seems impossible to me the think of all possible effects/problems ;-) What I don't understand is, why is os following so early/at all? Is the os project more or less blindly following fedora design decisions now? How about not copying this feature over (or to be more precise: disable it completely, which might let us use the original semantics for how) and see how fredora survives the coming weeks. Once they've found the very ugly stuff we may look at lessons learned and then enable this or continue to disable it. :wq Ciao Jörg -- Joerg Mayer <jmayer@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 27/03/12 19:16, Joerg Mayer escribió:
What I don't understand is, why is os following so early/at all? Is the os project more or less blindly following fedora design decisions now?
sharing policies and implementation details with other mayor distributions will actually save us from a lot of work and reinvention. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
El 27/03/12 19:16, Joerg Mayer escribió:
What I don't understand is, why is os following so early/at all? Is the os project more or less blindly following fedora design decisions now?
sharing policies and implementation details with other mayor distributions will actually save us from a lot of work and reinvention.
Leaving bleeding edge implementation details to other distributions will save us even more work and reinvention. -- Per Jessen, Zürich (5.2°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-28 07:47, Per Jessen wrote:
Cristian Rodríguez wrote:
sharing policies and implementation details with other mayor distributions will actually save us from a lot of work and reinvention.
Leaving bleeding edge implementation details to other distributions will save us even more work and reinvention.
Indeed. And suffering. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yx+EACgkQIvFNjefEBxo2rQCfQccz4sUbDB8wMa6Rlsfi2HqL lAMAmQF3uhOew+oj6ZtrUzqsIJd+5vgW =li+Z -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 27 March 2012 20:17:59 Cristian Rodríguez wrote:
El 27/03/12 19:16, Joerg Mayer escribió:
What I don't understand is, why is os following so early/at all? Is the os project more or less blindly following fedora design decisions now?
sharing policies and implementation details with other mayor distributions will actually save us from a lot of work and reinvention.
Yup. Plus that systemd is simply an upstream project, like it or not. I do support that we try to follow them, but not too fast (let Fedora test it for us please, that's what they do after all - test new stuff) and surely not like headless chickens. This move seems wrong to me... Esp for low-memory systems.
Le mercredi 28 mars 2012 à 16:47 +0200, Jos Poortvliet a écrit :
On Tuesday 27 March 2012 20:17:59 Cristian Rodríguez wrote:
El 27/03/12 19:16, Joerg Mayer escribió:
What I don't understand is, why is os following so early/at all? Is the os project more or less blindly following fedora design decisions now?
sharing policies and implementation details with other mayor distributions will actually save us from a lot of work and reinvention.
Yup. Plus that systemd is simply an upstream project, like it or not. I do support that we try to follow them, but not too fast (let Fedora test it for us please, that's what they do after all - test new stuff) and surely not like headless chickens. This move seems wrong to me... Esp for low-memory systems.
I forgot to mention in my initial mail we should probably restrict the maximum size of tmpfs /tmp (so it doesn't hit swap). Debian is doing this already, so it might be worth looking at their work ( http://lists.debian.org/debian-user/2012/03/msg01713.html ). They also had/have their set of flames and bug reports. I'll try to put everything on our wiki, for easier reference. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 27 mars 2012 à 23:48 +0200, Jiri Slaby a écrit :
On 03/27/2012 06:08 PM, Frederic Crozat wrote:
- /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
This will break a ton of boxes. * People won't be able to hibernate because their memory will be full of temp undroppable bloat.
Let's see how much bloat we can fix, and if eventually, we find too much we can't fix, we can ship with /tmp non-tmpfs.
* The overall system performance will be *hugely* reduced. Again, because the memory will be full of temp bloat, not having memory for gluttonous firefox.
Let's fix firefox so it uses /var/tmp instead of /tmp.
Yes, I still have a notebook with 2G of memory. I still have a 386 box with 512M of memory. And both are currently on the edge. No, thanks, I really don't want any more swapping.
Did they think about this change thoroughly?
I'm not going to do the messenger back and forth with systemd authors. Feel free to raise those topics with them directly.
(And yes, I have /tmp as tmpfs on my 6G-of-RAM machine.)
BTW stateless /tmp can be achieved by rm -rf /tmp/* at each boot.
Except it implies touching the disk.. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 of March 2012 11:57EN, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 23:48 +0200, Jiri Slaby a écrit :
* The overall system performance will be *hugely* reduced. Again, because the memory will be full of temp bloat, not having memory for gluttonous firefox.
Let's fix firefox so it uses /var/tmp instead of /tmp.
The problem is not Firefox using too much space in /tmp (well, it might be, too) but Firefox needing a lot of memory - which it will have to compete for with /tmp.
Did they think about this change thoroughly?
I'm not going to do the messenger back and forth with systemd authors. Feel free to raise those topics with them directly.
You are the person who plans to push these changes into OpenSuSE, not them, that's why Jiri is addressing you. For some reason you seem to believe that OpenSuSE has to unconditionally copy every design decision made by systemd developers and/or Fedora. But this is not true. Many packages in the distribution have defaults different from upstream projects to make the distribution more usable for its users. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 14:17 +0200, Michal Kubeček a écrit :
On Wednesday 28 of March 2012 11:57EN, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 23:48 +0200, Jiri Slaby a écrit :
* The overall system performance will be *hugely* reduced. Again, because the memory will be full of temp bloat, not having memory for gluttonous firefox.
Let's fix firefox so it uses /var/tmp instead of /tmp.
The problem is not Firefox using too much space in /tmp (well, it might be, too) but Firefox needing a lot of memory - which it will have to compete for with /tmp.
Ok, I misunderstood you.
Did they think about this change thoroughly?
I'm not going to do the messenger back and forth with systemd authors. Feel free to raise those topics with them directly.
You are the person who plans to push these changes into OpenSuSE, not them, that's why Jiri is addressing you.
Yes, but acting as a proxy between "communities" so such discussions is usually not efficient at all (this is usually why I ask people to report non-openSUSE bug reports upstream directly).
For some reason you seem to believe that OpenSuSE has to unconditionally copy every design decision made by systemd developers and/or Fedora. But this is not true. Many packages in the distribution have defaults different from upstream projects to make the distribution more usable for its users.
We also tend to think about openSUSE only and sometime not follow what our friends in various distributions are doing, just because some things were done in a certain way for specific reason in the past and they shouldn't change ever. /tmp as tmpfs is not a "Fedora" only thing. Debian has already switched to it (with its own set of controversy), Arch too. Fedora is planning to. So, it is a good time to think about it. If we feel we shouldn't do the switch, then, we won't do it. But we shouldn't just drop the case without proper investigation. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012, à 14:17 +0200, Michal Kubeček a écrit :
On Wednesday 28 of March 2012 11:57EN, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 23:48 +0200, Jiri Slaby a écrit :
Did they think about this change thoroughly?
I'm not going to do the messenger back and forth with systemd authors. Feel free to raise those topics with them directly.
You are the person who plans to push these changes into OpenSuSE, not them, that's why Jiri is addressing you.
For some reason you seem to believe that OpenSuSE has to unconditionally copy every design decision made by systemd developers and/or Fedora. But this is not true. Many packages in the distribution have defaults different from upstream projects to make the distribution more usable for its users.
Frédéric has been sending this mail to announce what changes are appearing in upstream systemd, and he wanted feedback for the integration in openSUSE. So he was doing the right thing here. Of course he can't know every rationale behind every design decisions upstream, and I don't think we should request that everyone contributing to openSUSE knows everything; it's fair to say "please ask upstream" to people for such requests. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 27 March 2012, Frederic Crozat wrote:
- /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on
This is absolutely stupid (at least having this per default). Would need a few 100GB big swap partition for most of my systems... cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-28 00:42, Ruediger Meier wrote:
On Tuesday 27 March 2012, Frederic Crozat wrote:
- /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on
This is absolutely stupid (at least having this per default). Would need a few 100GB big swap partition for most of my systems...
Yes. And many people are using very small swaps nowdays, there is no need for it if you have ample ram - which is not that ample if we have to reuse it for tmpfs. A very bad idea if users have not the choice about /tmp. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yS4wACgkQIvFNjefEBxrHCQCgsTtNcs2bLwviAbdWiAmDaqTU dpoAn2xUZZ/lUmlzlDS6qWjh2iagrgpB =HPU5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 27/03/12 19:42, Ruediger Meier escribió:
This is absolutely stupid (at least having this per default).
What is stupid is using a default suited for corner cases as yours. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-28 01:26, Cristian Rodríguez wrote:
El 27/03/12 19:42, Ruediger Meier escribió:
This is absolutely stupid (at least having this per default).
What is stupid is using a default suited for corner cases as yours.
I think the contrary, that it is your idea that is stupid, not ours. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yUu0ACgkQIvFNjefEBxoHIwCg2Cp3PCvIaj2Nx1vKmxn/moEU sz8AniqmrUlaR5A4bpeCupuaS/pjAE3M =TyLK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 March 2012, Cristian Rodríguez wrote:
El 27/03/12 19:42, Ruediger Meier escribió:
This is absolutely stupid (at least having this per default).
What is stupid is using a default suited for corner cases as yours.
It's stupid to give my users mini /tmp without caring about their use cases. And so it's stupid to change the default which satisfies a lot more use cases than tmpf. And even more stupid to import the default decision from an init system. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On woensdag 28 maart 2012 00:42:22 Ruediger Meier wrote:
On Tuesday 27 March 2012, Frederic Crozat wrote:
- /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on
This is absolutely stupid (at least having this per default). Would need a few 100GB big swap partition for most of my systems...
Wouldn't that mean that you don't need a few 100GB /tmp partition? So you trade a large /tmp partition for a large swap partition? The remaining question than is: what is more efficient? -- fr.gr. Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Wouldn't that mean that you don't need a few 100GB /tmp partition? So you trade a large /tmp partition for a large swap partition? The remaining question than is: what is more efficient?
You don't know if there even is a separate /tmp partition. Really, we should not debate if use cases are "wrong" but how a default of tmpfs can be implemented into openSUSE in a way not breaking advanced setups - -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yxXUACgkQCs1dsHJ/X7BMLQCfXaA7Cu3ZPpmV6NeJb5zjJmkG NqQAoKKsvymZkdqDpfY0ETsKaMkcWKre =P4qN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 March 2012, Ralf Lang wrote:
Wouldn't that mean that you don't need a few 100GB /tmp partition? So you trade a large /tmp partition for a large swap partition? The remaining question than is: what is more efficient?
You don't know if there even is a separate /tmp partition.
Really, we should not debate if use cases are "wrong" but how a default of tmpfs can be implemented into openSUSE in a way not breaking advanced setups
At least we must not change (shrink!) to tmpfs in the update case to not break working systems. And whether tmpfs on fresh is installed systems is a good default is IMO also very questionable. The only "advantage" is I see is that cleaning it on re-boot would be faster if you have a few 1000 files in /tmp which is also a "corner case". cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 09:34 +0100, Ruediger Meier a écrit :
On Wednesday 28 March 2012, Ralf Lang wrote:
Wouldn't that mean that you don't need a few 100GB /tmp partition? So you trade a large /tmp partition for a large swap partition? The remaining question than is: what is more efficient?
You don't know if there even is a separate /tmp partition.
Really, we should not debate if use cases are "wrong" but how a default of tmpfs can be implemented into openSUSE in a way not breaking advanced setups
At least we must not change (shrink!) to tmpfs in the update case to not break working systems.
I guess this could also be done automagically. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 March 2012, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 09:34 +0100, Ruediger Meier a écrit :
On Wednesday 28 March 2012, Ralf Lang wrote:
Wouldn't that mean that you don't need a few 100GB /tmp partition? So you trade a large /tmp partition for a large swap partition? The remaining question than is: what is more efficient?
You don't know if there even is a separate /tmp partition.
Really, we should not debate if use cases are "wrong" but how a default of tmpfs can be implemented into openSUSE in a way not breaking advanced setups
At least we must not change (shrink!) to tmpfs in the update case to not break working systems.
I guess this could also be done automagically.
On our desktop machines we have only one / partition to have /tmp and /var/tmp as large as possible. I guess any automatism would switch these default looking systems to tmpfs which would break all these systems. In update case the only automatism could be "use tmpfs only if it doesn't shrink current /tmp". For most existing systems this would be effectively the same like "never switch to tmpfs". So just don't change anything on update. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-28 09:48, Freek de Kruijf wrote:
On woensdag 28 maart 2012 00:42:22 Ruediger Meier wrote:
On Tuesday 27 March 2012, Frederic Crozat wrote:
- /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on
This is absolutely stupid (at least having this per default). Would need a few 100GB big swap partition for most of my systems...
Wouldn't that mean that you don't need a few 100GB /tmp partition? So you trade a large /tmp partition for a large swap partition? The remaining question than is: what is more efficient?
A /tmp partition. Or a 120 / partition. Where I can see the files even if it crashes. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yycMACgkQIvFNjefEBxqrwACgu/lNwvP7Ux8wD2e8+X+/RPCF mVwAoM7PhNet7k0vMSUo1A8uz/KVExNB =tmvw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Mar 28, 2012 at 4:48 AM, Freek de Kruijf <f.de.kruijf@gmail.com> wrote:
Wouldn't that mean that you don't need a few 100GB /tmp partition? So you trade a large /tmp partition for a large swap partition? The remaining question than is: what is more efficient?
Certainly it's far more efficient to have a 100G /tmp. When it's a partition for /tmp, it does not contend for RAM with other processes, except for write caching (which means it will still use available RAM to avoid writing to disk if possible). Not only that, but access patterns will be optimized for disk access, which will probably mean transfers around 20MB/s under a mixed load (sequential and random). When it's just swap, tmpfs will contend with other processes, possibly pushing process memory to disk far more frequently. This decreases those processes' performance, but it also results in the possibility of runaway processes: processes that require 50G of RAM will get an OOM when running without swap, but when using a 100G swap partition will get the request granted happily, and the performance drop that entails. Remember a thrashing system is usually only recoverable with a hard reset. Now, even under ideal conditions (where no process pages are swapped to disk and only tmpfs memory is swapped), the VM system is not optimized for this situation. Access patterns will most certainly be random, resulting in transfer speeds of 1MB/s or less. So... what's the best option? Ie: tmpfs is only useful for really small tmpfs partitions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Mar 28, 2012 at 11:40:19AM -0300, Claudio Freire wrote:
When it's just swap, tmpfs will contend with other processes, possibly pushing process memory to disk far more frequently. This decreases those processes' performance, but it also results in the possibility of runaway processes: processes that require 50G of RAM will get an OOM when running without swap, but when using a 100G swap partition will get the request granted happily, and the performance drop that entails.
Remember a thrashing system is usually only recoverable with a hard reset.
Are you still using swap? With the current ram prices, I don't bother to add any swap anymore. How much swap is used in your system (try 'free -m')? I prefer to just add a bit more mem and don't have a trashing system anymore. (Instead of trashing the OOM killer will just kill some process, hopefully the right one ;) ) Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Mar 28, 2012 at 11:54 AM, Michael Schroeder <mls@suse.de> wrote:
Are you still using swap? With the current ram prices, I don't bother to add any swap anymore. How much swap is used in your system (try 'free -m')? I prefer to just add a bit more mem and don't have a trashing system anymore. (Instead of trashing the OOM killer will just kill some process, hopefully the right one ;) )
I use swap in order to hibernate. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michael Schroeder (mls@suse.de) wrote:
On Wed, Mar 28, 2012 at 11:40:19AM -0300, Claudio Freire wrote:
Remember a thrashing system is usually only recoverable with a hard reset.
Are you still using swap? With the current ram prices, I don't bother to add any swap anymore. How much swap is used in your system (try 'free -m')? I prefer to just add a bit more mem and don't have a trashing system anymore. (Instead of trashing the OOM killer will just kill some process, hopefully the right one ;) )
Agreed - OOM killer is in many cases far preferable to endless thrashing. OTOH, here is a very old (2004) article that argues there are still good reasons for swap: http://sourcefrog.net/weblog/software/linux-kernel/swap.html I'd be interested to hear opinions on how much of it is still relevant. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/28/2012 12:22 PM, Adam Spiers wrote:
Michael Schroeder (mls@suse.de) wrote:
On Wed, Mar 28, 2012 at 11:40:19AM -0300, Claudio Freire wrote:
Remember a thrashing system is usually only recoverable with a hard reset.
Are you still using swap? With the current ram prices, I don't bother to add any swap anymore. How much swap is used in your system (try 'free -m')? I prefer to just add a bit more mem and don't have a trashing system anymore. (Instead of trashing the OOM killer will just kill some process, hopefully the right one ;) )
Agreed - OOM killer is in many cases far preferable to endless thrashing. OTOH, here is a very old (2004) article that argues there are still good reasons for swap:
http://sourcefrog.net/weblog/software/linux-kernel/swap.html
I'd be interested to hear opinions on how much of it is still relevant.
If you want to have a discussion about swap space please start a different thread on another list as this has nothing to do with factory or the initial post. -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Mar 28, 2012 at 12:44:33PM -0400, Robert Schweikert wrote:
If you want to have a discussion about swap space please start a different thread on another list as this has nothing to do with factory or the initial post.
Well, no configured swap makes tmp on tmpfs a really bad move... M. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 27 Mar 2012, Frederic Crozat wrote:
Hi all,
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) - /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
Btw, I see that TMPDIR is /tmp by default on 12.1. GCC uses this for all temporary files, for link-time optimizing firefox for example you need about 4GB of storage in TMPDIR. Thus, consider that (apart from my own personal opinion that a stateless /tmp is utterly stupid, a tmpfs /tmp is even more so). So, change TMPDIR to point to /var/tmp? Which would of course make /tmp quite useless. Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Le mercredi 28 mars 2012 à 10:18 +0200, Richard Guenther a écrit :
On Tue, 27 Mar 2012, Frederic Crozat wrote:
Hi all,
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) - /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
Btw, I see that TMPDIR is /tmp by default on 12.1. GCC uses this for all temporary files, for link-time optimizing firefox for example you need about 4GB of storage in TMPDIR.
Thus, consider that (apart from my own personal opinion that a stateless /tmp is utterly stupid, a tmpfs /tmp is even more so).
So, change TMPDIR to point to /var/tmp? Which would of course make /tmp quite useless.
Indeed, for this use case, it is problematic. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 28 Mar 2012, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 10:18 +0200, Richard Guenther a écrit :
On Tue, 27 Mar 2012, Frederic Crozat wrote:
Hi all,
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) - /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
Btw, I see that TMPDIR is /tmp by default on 12.1. GCC uses this for all temporary files, for link-time optimizing firefox for example you need about 4GB of storage in TMPDIR.
Thus, consider that (apart from my own personal opinion that a stateless /tmp is utterly stupid, a tmpfs /tmp is even more so).
So, change TMPDIR to point to /var/tmp? Which would of course make /tmp quite useless.
Indeed, for this use case, it is problematic.
Any better portable suggestion? TMPDIR is what I thought was the proper place to store temporary files. Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
On Wednesday 28 March 2012 12:08:33 Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 10:18 +0200, Richard Guenther a écrit :
On Tue, 27 Mar 2012, Frederic Crozat wrote:
Hi all,
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) - /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
Btw, I see that TMPDIR is /tmp by default on 12.1. GCC uses this for all temporary files, for link-time optimizing firefox for example you need about 4GB of storage in TMPDIR.
Thus, consider that (apart from my own personal opinion that a stateless /tmp is utterly stupid, a tmpfs /tmp is even more so).
So, change TMPDIR to point to /var/tmp? Which would of course make /tmp quite useless.
Indeed, for this use case, it is problematic.
... and for anyone using Inkscape or Gimp or other apps with big files. Oh and flash saves big files in /tmp too. And thumbnailers have a tendency to eat space there. I just removed 1.4 gb of thumbnail files from /tmp. and that's with an 2 day uptime! I already have /tmp mounted tmpfs on my laptop to save the SSD and it very frequently leads to weird problems. I often simply check /tmp if apps are randomly crashing these days... In short, I would STRONGLY recommend against mounting /tmp tmpfs. That ONLY works for advanced users as they can fix the resulting problems themselves. Anyone who keeps their PC on for a longer period of time will see that folder grow and grow and grow. Eating memory instead of diskspace is bad in itself, running out of space there is worse... just my few cents...
On Wed, Mar 28, 2012 at 11:38 AM, Jos Poortvliet <jos@opensuse.org> wrote:
In short, I would STRONGLY recommend against mounting /tmp tmpfs. That ONLY works for advanced users as they can fix the resulting problems themselves. Anyone who keeps their PC on for a longer period of time will see that folder grow and grow and grow. Eating memory instead of diskspace is bad in itself, running out of space there is worse...
I recommend the opposite. I recommend doing this move with a small tmpfs early in the release cycle, so that testers can weed out misbehaving apps (like gimp). Those apps should be using /var/tmp. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 11:41 -0300, Claudio Freire a écrit :
On Wed, Mar 28, 2012 at 11:38 AM, Jos Poortvliet <jos@opensuse.org> wrote:
In short, I would STRONGLY recommend against mounting /tmp tmpfs. That ONLY works for advanced users as they can fix the resulting problems themselves. Anyone who keeps their PC on for a longer period of time will see that folder grow and grow and grow. Eating memory instead of diskspace is bad in itself, running out of space there is worse...
I recommend the opposite. I recommend doing this move with a small tmpfs early in the release cycle, so that testers can weed out misbehaving apps (like gimp). Those apps should be using /var/tmp.
To be more precise, Lennart (systemd author) has put some developer oriented informations about /tmp in a post blog : http://0pointer.de/blog/projects/tmp.html -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 28 Mar 2012, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 11:41 -0300, Claudio Freire a écrit :
On Wed, Mar 28, 2012 at 11:38 AM, Jos Poortvliet <jos@opensuse.org> wrote:
In short, I would STRONGLY recommend against mounting /tmp tmpfs. That ONLY works for advanced users as they can fix the resulting problems themselves. Anyone who keeps their PC on for a longer period of time will see that folder grow and grow and grow. Eating memory instead of diskspace is bad in itself, running out of space there is worse...
I recommend the opposite. I recommend doing this move with a small tmpfs early in the release cycle, so that testers can weed out misbehaving apps (like gimp). Those apps should be using /var/tmp.
To be more precise, Lennart (systemd author) has put some developer oriented informations about /tmp in a post blog :
Hmm. 6. Otherwise use $TMPDIR with a fallback on /var/tmp. Also use mkstemp()/mkdtemp(). that's what the GCC case applies to. Which means $TMPDIR be better _not_ /tmp. ? Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Le jeudi 29 mars 2012 à 10:54 +0200, Richard Guenther a écrit :
On Wed, 28 Mar 2012, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 11:41 -0300, Claudio Freire a écrit :
On Wed, Mar 28, 2012 at 11:38 AM, Jos Poortvliet <jos@opensuse.org> wrote:
In short, I would STRONGLY recommend against mounting /tmp tmpfs. That ONLY works for advanced users as they can fix the resulting problems themselves. Anyone who keeps their PC on for a longer period of time will see that folder grow and grow and grow. Eating memory instead of diskspace is bad in itself, running out of space there is worse...
I recommend the opposite. I recommend doing this move with a small tmpfs early in the release cycle, so that testers can weed out misbehaving apps (like gimp). Those apps should be using /var/tmp.
To be more precise, Lennart (systemd author) has put some developer oriented informations about /tmp in a post blog :
Hmm.
6. Otherwise use $TMPDIR with a fallback on /var/tmp. Also use mkstemp()/mkdtemp().
that's what the GCC case applies to. Which means $TMPDIR be better _not_ /tmp.
?
With tmpfs /tmp, probably, regarding the memory usage of it.. Feel free to discuss the topic with Lennart in the comments on the page. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 29 March 2012, Richard Guenther wrote:
On Wed, 28 Mar 2012, Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 11:41 -0300, Claudio Freire a écrit :
On Wed, Mar 28, 2012 at 11:38 AM, Jos Poortvliet <jos@opensuse.org> wrote:
In short, I would STRONGLY recommend against mounting /tmp tmpfs. That ONLY works for advanced users as they can fix the resulting problems themselves. Anyone who keeps their PC on for a longer period of time will see that folder grow and grow and grow. Eating memory instead of diskspace is bad in itself, running out of space there is worse...
I recommend the opposite. I recommend doing this move with a small tmpfs early in the release cycle, so that testers can weed out misbehaving apps (like gimp). Those apps should be using /var/tmp.
To be more precise, Lennart (systemd author) has put some developer oriented informations about /tmp in a post blog :
Hmm.
6. Otherwise use $TMPDIR with a fallback on /var/tmp. Also use mkstemp()/mkdtemp().
that's what the GCC case applies to. Which means $TMPDIR be better _not_ /tmp.
Files which are not needed in after reboot or which are safe to be deleted frequently during uptime should IMO always go to /tmp regardless how large they are. Moving them to /var/tmp would consume even more space because it's cleaned up less frequently. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 Mar 2012 16:38:38 Jos Poortvliet wrote:
In short, I would STRONGLY recommend against mounting /tmp tmpfs. That ONLY works for advanced users as they can fix the resulting problems themselves. Anyone who keeps their PC on for a longer period of time will see that folder grow and grow and grow. Eating memory instead of diskspace is bad in itself, running out of space there is worse...
That's not the pattern of usage for a tmpfs /tmp that I see. I'm certainly not a lightweight user and usually run with longish uptimes between the kernel updates. At home I have my /tmp tmps limit at 1GB on my 16GB system, the 8GB & 4GB systems run 512MB & 256MB respectively. I use the largest RAM machine as my main workstation. I don't currently set /tmp to be tmpfs on servers, but I plan to in future. Currently on the largest RAM machine that I use as my main workstation, with a modest 27 days up /tmp is consuming 179MB, with 173MB of that being chromium cache. In practice I find *most* software and scripts behave very well in how they use /tmp. I've been using tmpfs /tmp since 11.3 and It's true, once or twice that I can remember, I have had software not work correctly because /tmp was full. The first occasion was from watching a long Flash video in Firefox. The second occasion was either Audacity or Spotify filling /tmp as it's scratch disk. The flash problem went away when I stopped browsing with Firefox and switched to Chromium. The second problem was of course trivially fixable, all reasonable applications that might use a large scratch disk have easily configurable scratch locations in the options/preferences. Of course these two times when software failed due to a full /tmp are in my opinion much preferable to the alternative. The alternative is that when /tmp is a physical volume and badly behaved software fills the whole volume (usually the / volume as well) the whole system is brought to it's knees. This has happened to me often enough from badly written scripts, bugs or software and is the main reason I started using tmpfs /tmp. One other side thing, which might be nice for some users, is sometimes noticable performance benefit from having caches (including browser cache) in tmpfs /tmp. The other benefit I am looking forward to, if we progress far enough with the "/usr" move, is read only / , and so tmpfs /tmp to me makes perfect sense. So in summary I agree with what most people want. Lets *not* introduce any *surprises* on upgrade and if we can make this sensibly configurable too outside of any defaults on a new install (if we go down this route). However I think it does make sense (with tangible benefits) to consider tmpfs /tmp for most desktop users. Lets face it, if you're a power user who is going to be using _large_ amounts of /tmp due to scripts, data manipulation, compiling or using "power apps", you're more than capable of configuring your system to compensate. I see Firefox + Flash as an issue on this though, what can we do about that? Cheers the noo, Graham -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Mar 28, 2012 at 1:09 PM, Graham Anderson <graham.anderson@gmail.com> wrote:
Of course these two times when software failed due to a full /tmp are in my opinion much preferable to the alternative. The alternative is that when /tmp is a physical volume and badly behaved software fills the whole volume (usually the / volume as well) the whole system is brought to it's knees. This has happened to me often enough from badly written scripts, bugs or software and is the main reason I started using tmpfs /tmp.
Why would it be brought to its knees? Just as tmpfs is, persistent /tmp is also cleaned up (albeit explicitly with a cleanup script) at boot time. I like your sizes though (1 16th of RAM sounds ok). Notice, though, that it means only 8M for a 128MB system. Still, from my experience with debian, with properly behaving apps 8M should be enough. Not for firefox as you noticed, or even chromium since any cache will eat more than 8M.
One other side thing, which might be nice for some users, is sometimes noticable performance benefit from having caches (including browser cache) in tmpfs /tmp.
I would only argue about battery life improvements, not performance gains. The kernel's write cache already gets you the same performance with a disk-based filesystem, but disk activity drains the battery. That, and security - when sensitive information is spilled into /tmp, having it be on tmpfs and be completely volatile improves security a great deal. Remember that information leak recently found in gnome-terminal (where the entire scrollback buffer was being leaked to /tmp). That's a very important incentive for the switch to tmpfs IMO.
However I think it does make sense (with tangible benefits) to consider tmpfs /tmp for most desktop users. Lets face it, if you're a power user who is going to be using _large_ amounts of /tmp due to scripts, data manipulation, compiling or using "power apps", you're more than capable of configuring your system to compensate.
I see Firefox + Flash as an issue on this though, what can we do about that?
Easy, configure firefox to use /var/tmp. Notice that this move will probably require a re-evaluation of the proposed partition schemes in the installer. Now /var will be bigger, /tmp nonexistent, and who knows how that ripples. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Claudio Freire wrote:
On Wed, Mar 28, 2012 at 1:09 PM, Graham Anderson <graham.anderson@gmail.com> wrote:
Of course these two times when software failed due to a full /tmp are in my opinion much preferable to the alternative. The alternative is that when /tmp is a physical volume and badly behaved software fills the whole volume (usually the / volume as well) the whole system is brought to it's knees. This has happened to me often enough from badly written scripts, bugs or software and is the main reason I started using tmpfs /tmp.
Why would it be brought to its knees? Just as tmpfs is, persistent /tmp is also cleaned up (albeit explicitly with a cleanup script) at boot time.
Not by default I think. (not on any of my systems running 12.2Mx)
However I think it does make sense (with tangible benefits) to consider tmpfs /tmp for most desktop users. Lets face it, if you're a power user who is going to be using _large_ amounts of /tmp due to scripts, data manipulation, compiling or using "power apps", you're more than capable of configuring your system to compensate.
I see Firefox + Flash as an issue on this though, what can we do about that?
Easy, configure firefox to use /var/tmp.
Notice that this move will probably require a re-evaluation of the proposed partition schemes in the installer. Now /var will be bigger, /tmp nonexistent, and who knows how that ripples.
Did we ever propose partitions for /var and /tmp? -- Per Jessen, Zürich (17.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Mar 28, 2012 at 2:03 PM, Per Jessen <per@computer.org> wrote:
Notice that this move will probably require a re-evaluation of the proposed partition schemes in the installer. Now /var will be bigger, /tmp nonexistent, and who knows how that ripples.
Did we ever propose partitions for /var and /tmp?
I don't remember all the partition setups, but if there wasn't a proposal for separate var, now there would be the need for one. Or you'd be writing on the root filesystem all the time, which is bad mojo. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Claudio Freire wrote:
On Wed, Mar 28, 2012 at 2:03 PM, Per Jessen <per@computer.org> wrote:
Notice that this move will probably require a re-evaluation of the proposed partition schemes in the installer. Now /var will be bigger, /tmp nonexistent, and who knows how that ripples.
Did we ever propose partitions for /var and /tmp?
I don't remember all the partition setups, but if there wasn't a proposal for separate var, now there would be the need for one. Or you'd be writing on the root filesystem all the time, which is bad mojo.
I'm pretty certain that is the current default. -- Per Jessen, Zürich (13.8°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2012-03-28 at 19:03 +0200, Per Jessen wrote:
Did we ever propose partitions for /var and /tmp?
wasn't the FSH saying somethinh about that.... hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Guenther wrote:
On Tue, 27 Mar 2012, Frederic Crozat wrote: [...] Btw, I see that TMPDIR is /tmp by default on 12.1. GCC uses this for all temporary files, for link-time optimizing firefox for example you need about 4GB of storage in TMPDIR.
Thus, consider that (apart from my own personal opinion that a stateless /tmp is utterly stupid, a tmpfs /tmp is even more so).
So, change TMPDIR to point to /var/tmp? Which would of course make /tmp quite useless.
Independent of whether or not to use tmpfs for /tmp from security PoV it would be desirable to set TMPDIR to a per user directory rather than one global 1777 dir to avoid tmp races in sloppy programmed applications. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 14:05 +0200, Ludwig Nussel a écrit :
Richard Guenther wrote:
On Tue, 27 Mar 2012, Frederic Crozat wrote: [...] Btw, I see that TMPDIR is /tmp by default on 12.1. GCC uses this for all temporary files, for link-time optimizing firefox for example you need about 4GB of storage in TMPDIR.
Thus, consider that (apart from my own personal opinion that a stateless /tmp is utterly stupid, a tmpfs /tmp is even more so).
So, change TMPDIR to point to /var/tmp? Which would of course make /tmp quite useless.
Independent of whether or not to use tmpfs for /tmp from security PoV it would be desirable to set TMPDIR to a per user directory rather than one global 1777 dir to avoid tmp races in sloppy programmed applications.
This is something we are doing at Mandrake / Mandriva for years (using TMPDIR=$HOME/tmp), but it has also its set of issues : - it didn't play nice at all with network mounted home - we had to patch some software (I remember gconf or ORBit) to make sure they were still using a "always local" TMPDIR and not one which could be shared across system. One possibility could be to use /run/<user>/ hierarchy which is now created by pam_systemd at login and erased at logout. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Frederic Crozat wrote:
Le mercredi 28 mars 2012 à 14:05 +0200, Ludwig Nussel a écrit :
Richard Guenther wrote:
On Tue, 27 Mar 2012, Frederic Crozat wrote: [...] Btw, I see that TMPDIR is /tmp by default on 12.1. GCC uses this for all temporary files, for link-time optimizing firefox for example you need about 4GB of storage in TMPDIR.
Thus, consider that (apart from my own personal opinion that a stateless /tmp is utterly stupid, a tmpfs /tmp is even more so).
So, change TMPDIR to point to /var/tmp? Which would of course make /tmp quite useless.
Independent of whether or not to use tmpfs for /tmp from security PoV it would be desirable to set TMPDIR to a per user directory rather than one global 1777 dir to avoid tmp races in sloppy programmed applications.
This is something we are doing at Mandrake / Mandriva for years (using TMPDIR=$HOME/tmp), but it has also its set of issues : - it didn't play nice at all with network mounted home - we had to patch some software (I remember gconf or ORBit) to make sure they were still using a "always local" TMPDIR and not one which could be shared across system.
One possibility could be to use /run/<user>/ hierarchy which is now created by pam_systemd at login and erased at logout.
And the third possibility would be to have the pam module create $TMPDIR on persistent storage somewhere below /var. That would avoid the trouble with NFS and not put anything into RAM. I wonder what kind of data actually ends up in TMPDIR if we separate it from /tmp and applications start honoring $XDG_DOWNLOAD_DIR and $XDG_CACHE_HOME though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 27 March 2012 20:08:01 Frederic Crozat wrote:
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora) - /tmp is mounted as tmpfs, to make the default setups as stateless as possible. As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage. Another big issue is educating users.
When will this change with /media be pushed into openSUSE? Is it expected for 12.2? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 28 mars 2012 à 20:10 +0400, Ilya Chernykh a écrit :
On Tuesday 27 March 2012 20:08:01 Frederic Crozat wrote:
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user>
When will this change with /media be pushed into openSUSE? Is it expected for 12.2?
I guess so (I don't know when new systemd release is due). -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 28 March 2012 20:27:44 Frederic Crozat wrote:
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user>
When will this change with /media be pushed into openSUSE? Is it expected for 12.2?
I guess so (I don't know when new systemd release is due).
What is about udisks2? Is it already in Factory? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ilya, Le mercredi 28 mars 2012, à 20:31 +0400, Ilya Chernykh a écrit :
On Wednesday 28 March 2012 20:27:44 Frederic Crozat wrote:
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user>
When will this change with /media be pushed into openSUSE? Is it expected for 12.2?
I guess so (I don't know when new systemd release is due).
What is about udisks2? Is it already in Factory?
This is completely off-topic for this thread, and you know you can check this easily by yourself, right? Try "osc search udisks2" for instance. (the answer is "yes, it's in Factory already") Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Frederic Crozat writes:
this is a announcement regarding changes which have just landed in upstream systemd (not yet released nor pushed to Factory) regarding /media and /tmp: - /media will no longer mounted as tmpfs. This is because udisks2 will no longer use /media for mounting removables devices but /run/media/<user>
Out of curiosity, how does one deal with media mounts that should be available system-wide?
- /var/run and /var/lock are no longer bind-mounted to /run | /run/lock. We should replace those directories with symlink to /run | /run/lock (probably at initrd time, this is what is done on Fedora)
Just make sure that this time around the former contents of these directories does not vanish as it did the last time when they were changed to tmpfs (i.e. rename them first before installiung the symlinks or mount-overs).
- /tmp is mounted as tmpfs, to make the default setups as stateless as possible.
I don't think this is sensible as a general default.
As stated on https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to fix some applications to use /var/tmp instead of /tmp when they need persistent storage.
I might agree on the "persistent storage" issue. But as has been said already, assert( "/tmp" != "/ramdisk" ) is built into many programs and it will be impossible to change all of them. We already have /var/tmp for "persistent" temporary storage. Applications that currently use /tmp for temporary files and directories that should ostensibly not be held in RAM, but should go away when the application for whatever reason doesn't delete them have no business to store their stuff in /var/tmp because nobody cleans up after them and if we start cleaning /var/tmp that would again break other legitimate uses. It would seem to make much more sense to introduce /run/tmp for "ephemeral" temporary storage in RAM and change those applications that don't need to commit to disk to use it than wholesale changing the semantics of /tmp. That doesn't preclude to change /tmp to tmpfs in situations where it is known to work correctly and where the benefits (power draw and SSD wear — really?) outweigh the potential problems. In other words, the "stateless system" that the proposal aims for is much more easily achieved by making the _system_ stop using /tmp and care only for /run/tmp (or maybe even /run/tmp/sys in a non-shared /run/tmp/<user> setup), which already is stateless.
Another big issue is educating users.
The big issue is third-party applications that would need to be changed, assuming that _all_ applications tat come with the distribution would be fixed already. What is the proposal for those, are you going to virtualize the file system like Win7 does? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 31/03/12 05:21, Achim Gratz escribió:
Just make sure that this time around the former contents of these directories does not vanish as it did the last time when they were changed to tmpfs (i.e. rename them first before installiung the symlinks or mount-overs).
No, read the documentation: "This directory contains system information data describing the system since it was booted. ****Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process*** " -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez writes:
No, read the documentation:
No, you go and check what the update really did instead of what it should have been doing. Those files are still there, not accessible and when systemd stops putting a tmpfs mount at it they will become accessible again, so trying to make a symlink in the same place will fail until they are removed or renamed.
"This directory contains system information data describing the system since it was booted. ****Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process*** "
But when switching to systemd it didn't do that and papered a tmpfs mount over a directory that wasn't empty as it didn't care to check this assumption. Besides, the former system didn't clear those files at all (that's been another bug, AFAIK). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Mar 31, 2012 at 5:21 AM, Achim Gratz <Stromeko@nexgo.de> wrote:
It would seem to make much more sense to introduce /run/tmp for "ephemeral" temporary storage in RAM and change those applications that don't need to commit to disk to use it than wholesale changing the semantics of /tmp.
I'd buy that. Mostly because even though /tmp is supposed to be volatile, there's nothing said about the size of things in it. gnome-terminal, ssh and many others could be made to use /run/tmp instead, and I think that would be progress. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Mar 31, 2012 at 5:21 AM, Achim Gratz <Stromeko@nexgo.de> wrote:
That doesn't preclude to change /tmp to tmpfs in situations where it is known to work correctly and where the benefits (power draw and SSD wear — really?) outweigh the potential problems.
Those benefits could be obtained by using ext3 with commit=3600. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (34)
-
Achim Gratz -
Adam Spiers -
Andreas Jaeger -
Brian K. White -
Bruno Friedmann -
Carlos E. R. -
Carlos E. R. -
Claudio Freire -
Cristian Rodríguez -
Dean Hilkewich -
Frederic Crozat -
Freek de Kruijf -
Graham Anderson -
Hans Witvliet -
Ilya Chernykh -
Jiri Slaby -
Joerg Mayer -
Jon Nelson -
Jos Poortvliet -
Lars Müller -
Ludwig Nussel -
Matthias G. Eckermann -
Michael Schroeder -
Michal Kubecek -
Michal Kubeček
-
Per Jessen -
Per Jessen -
Ralf Lang -
Richard Guenther -
Robert Schweikert -
Ruediger Meier -
Stefan Seyfried -
Takashi Iwai -
Vincent Untz