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

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 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 à 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 SUSE -- 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

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 SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer

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

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 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-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

-----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

-----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

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

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

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 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?

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 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 03:48:30PM -0300, Claudio Freire wrote:

On Tue, Mar 27, 2012 at 3:39 PM, Bruno Friedmann 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

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 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 6:48 PM, Jiri Slaby 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

On Tue, Mar 27, 2012 at 8:20 PM, Cristian Rodríguez 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

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 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 à 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 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 à 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 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/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

-----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

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

-----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

-----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 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 Tue, Mar 27, 2012 at 8:20 PM, Cristian Rodríguez 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

On Tue, Mar 27, 2012 at 10:43 PM, Jon Nelson 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

-----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

-----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

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 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

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

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 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 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 :

...

* 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 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 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

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

-----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

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 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 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 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

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 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

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 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 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...

Le mercredi 28 mars 2012 à 11:41 -0300, Claudio Freire a écrit :

On Wed, Mar 28, 2012 at 11:38 AM, 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...

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 SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 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

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 SUSE -- 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

Claudio Freire wrote:

On Wed, Mar 28, 2012 at 1:09 PM, Graham Anderson 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

Claudio Freire wrote:

On Wed, Mar 28, 2012 at 2:03 PM, Per Jessen 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

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

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

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 SUSE -- 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

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

On Sat, Mar 31, 2012 at 5:21 AM, Achim Gratz 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