=================================== #fedora-meeting: FESCO (2012-04-02) ===================================
Meeting started by mitr at 17:00:54 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-04-02/fesco.2012-04-02-... .
Meeting summary --------------- * init process (mitr, 17:01:06)
* #830 define requirements for secondary arch promotion (mitr, 17:05:02) * LINK: http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_... (mjg59, 17:05:46) * LINK: http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_...) (nirik, 17:05:46) * AGREED: wait a week for more discussion on list, vote on critera draft (mitr, 17:18:27)
* #833 Remove provenpackagers access to libvirt related packages (mitr, 17:18:36) * Provenpackagers please try to contact the maintainers first (if possible) before you commit changes to a package. (t8m, 17:30:30) * ACTION: mmaslano will draft provenpackager policy changes (mitr, 17:39:47)
* #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
* #835 F18 Feature: GHC 7.4 - https://fedoraproject.org/wiki/Features/GHC74 (mitr, 18:13:03) * AGREED: GHC7.4 is accepted (+7 ) (mitr, 18:15:13)
* Next week's chair (mitr, 18:15:31) * ACTION: nirik will chair next meeting (mitr, 18:16:21)
* Open Floor (mitr, 18:16:26) * AGREED: the meeting on April 9 is canceled (mitr, 18:19:07)
* Open Floor (mitr, 18:19:28)
Meeting ended at 18:22:28 UTC.
Action Items ------------ * mmaslano will draft provenpackager policy changes * nirik will chair next meeting
Action Items, by person ----------------------- * mmaslano * mmaslano will draft provenpackager policy changes * nirik * nirik will chair next meeting * **UNASSIGNED** * (none)
People Present (lines said) --------------------------- * mitr (106) * mezcalero (62) * mjg59 (59) * nirik (36) * pjones (34) * limburgher (27) * mmaslano (24) * t8m (18) * danpb (16) * notting (15) * kay (15) * zodbot (8) * bconoboy (8) * rbergeron (1) * drago01 (1) * brunowolff (1) * sgallagh (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
- it doesn't support O_DIRECT
- it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work
All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed.
Rich.
On 04/02/2012 15:58, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr,
17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
it's very limited in space compared to a real disk
it doesn't support O_DIRECT
it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work
All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
I really need to remember to send with the right user identity for this list.
<resend of my message since its going to bounce>
That third part is not correct. tmpfs supports SELinux labels. If you mount a tmpfs filesystem you'll see it reports seclabel as one of the mount options. You can also just use chcon -t to set the type on any file you like. SELinux labels are stored in the security namespace which is separate from user extended attributes.
Dave
On Mon, Apr 02, 2012 at 04:04:23PM -0400, David Quigley wrote:
On 04/02/2012 15:58, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
it's very limited in space compared to a real disk
it doesn't support O_DIRECT
it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work
All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
I really need to remember to send with the right user identity for this list.
<resend of my message since its going to bounce>
That third part is not correct. tmpfs supports SELinux labels. If you mount a tmpfs filesystem you'll see it reports seclabel as one of the mount options. You can also just use chcon -t to set the type on any file you like. SELinux labels are stored in the security namespace which is separate from user extended attributes.
That's not what I said. I said that relatively recent kernels (up to the middle of last year) didn't support system.*, and tmpfs doesn't support user.* at all AFAICT.
Rich.
On 04/02/2012 16:06, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 04:04:23PM -0400, David Quigley wrote:
On 04/02/2012 15:58, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little
visibility
to the user."
tmpfs is different in a number of important ways:
it's very limited in space compared to a real disk
it doesn't support O_DIRECT
it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work
All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
I really need to remember to send with the right user identity for this list.
<resend of my message since its going to bounce>
That third part is not correct. tmpfs supports SELinux labels. If you mount a tmpfs filesystem you'll see it reports seclabel as one of the mount options. You can also just use chcon -t to set the type on any file you like. SELinux labels are stored in the security namespace which is separate from user extended attributes.
That's not what I said. I said that relatively recent kernels (up to the middle of last year) didn't support system.*, and tmpfs doesn't support user.* at all AFAICT.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
I wasn't contesting your statement of user.* and system.* I was just pointing out that tmpfs has supported SELinux labels for a very long time. Even well before Eric's patch last year that put generic xattr handlers in. So there should be no issue at all with SELinux labels on tmpfs even if you run older kernels.
Dave
On Mon, Apr 02, 2012 at 04:11:24PM -0400, David Quigley wrote:
On 04/02/2012 16:06, Richard W.M. Jones wrote:
That's not what I said. I said that relatively recent kernels (up to the middle of last year) didn't support system.*, and tmpfs doesn't
Sorry, I meant to write security.* there.
support user.* at all AFAICT.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
I wasn't contesting your statement of user.* and system.* I was just pointing out that tmpfs has supported SELinux labels for a very long time. Even well before Eric's patch last year that put generic xattr handlers in. So there should be no issue at all with SELinux labels on tmpfs even if you run older kernels.
Are you sure about this? '-o seclabel' has been backported to RHEL 6, but it doesn't exist on RHEL 5, nor on (upstream) 2.6.39 AFAICS.
Rich.
On 04/02/2012 16:26, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 04:11:24PM -0400, David Quigley wrote:
On 04/02/2012 16:06, Richard W.M. Jones wrote:
That's not what I said. I said that relatively recent kernels (up
to
the middle of last year) didn't support system.*, and tmpfs doesn't
Sorry, I meant to write security.* there.
support user.* at all AFAICT.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
I wasn't contesting your statement of user.* and system.* I was just pointing out that tmpfs has supported SELinux labels for a very long time. Even well before Eric's patch last year that put generic xattr handlers in. So there should be no issue at all with SELinux labels on tmpfs even if you run older kernels.
Are you sure about this? '-o seclabel' has been backported to RHEL 6, but it doesn't exist on RHEL 5, nor on (upstream) 2.6.39 AFAICS.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
You don't specify seclabel as an option. It is something that is put into the mount command to show you that a filesystem supports being able to set security labels on it. I wrote that patch back in 2009 sometime I think. Seclabel just says that the filesystem is being labeled with xattrs, transition, or task labeling types. In all of these cases in the event of an xattr handler not being present it will fall back on the LSM via vfs_set/gatxattr to set the label on the incore inode. So whether or not RHEL 5 reports seclabel in the mount options is irrelevant because its just notifying you of behavior that already existed.
Dave
On Mon, Apr 02, 2012 at 04:40:38PM -0400, David Quigley wrote:
You don't specify seclabel as an option. It is something that is put into the mount command to show you that a filesystem supports being able to set security labels on it.
OK, I see. In fact I tested this and I was able to set SELinux labels on RHEL 5 tmpfs, so this does work.
Rich.
On Mon, Apr 2, 2012 at 9:58 PM, Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
Which does not really matter in practice.
- it doesn't support O_DIRECT
Neither does this (which apps needs O_DIRECT on /tmp ? ).
- it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work
Huh? Why would you run a "very old kernel" on fedora?
All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed.
Sure if bugs are found they should be fixed. But note I have been doing this testing for a *long* time (long as in years) on different systems and yet have to find a package that breaks.
On Mon, Apr 02, 2012 at 10:24:38PM +0200, drago01 wrote:
On Mon, Apr 2, 2012 at 9:58 PM, Richard W.M. Jones rjones@redhat.com wrote:
- it doesn't support O_DIRECT
Neither does this (which apps needs O_DIRECT on /tmp ? ).
qemu and libguestfs as it turned out. It was one of the things we had to fix when we first ported to Debian.
It's not completely unusual that an application should want to directly access a cache file, bypassing the page cache, nor that it would want to store such a file in /tmp. My point was that these things will be discovered when we test every application.
- it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work
Huh? Why would you run a "very old kernel" on fedora?
It's not unknown that people use different kernels from the ones supplied. I said "not very old", by which I meant >= 12 months old.
Rich.
Richard W.M. Jones (rjones@redhat.com) said:
- it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work
Huh? Why would you run a "very old kernel" on fedora?
It's not unknown that people use different kernels from the ones supplied. I said "not very old", by which I meant >= 12 months old.
That doesn't mean they're not voiding their (admittedly nonexistent) warranty when they do so.
Bill
On Mon, 02.04.12 21:30, Richard W.M. Jones (rjones@redhat.com) wrote:
- it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work
Huh? Why would you run a "very old kernel" on fedora?
It's not unknown that people use different kernels from the ones supplied. I said "not very old", by which I meant >= 12 months old.
SELinux on tmpfs has been supported at least as long as we made devtmpfs the default on Fedora, since that's more or less just a tmpfs like any other when it comes to features.
Lennart
On Mon, 02.04.12 20:58, Richard W.M. Jones (rjones@redhat.com) wrote: Heya,
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
Well, i'd claim this is not really user visible if implemented correctly. This is however visible to the developer.
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
Yes, large files need to be placed on /var/tmp, which is explained in the feature page.
- it doesn't support O_DIRECT
Well, all code using O_DIRECT should probably have a fallback to work without, anyway, and very likely has. O_DIRECT doesn't really make sense for tmpfs, it isn't really a feature that currently isn't supported and could be implemented, it is something that genuinly makes little sense for tmpfs...
- it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work
We do this change for F18, not for old Fedora with old kernels. SELinux labels work fine on tmpfs. User xattr patches have recently been posted on lkml, but indeed are not supported right now.
All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed.
But yes, this is absolutely true. We do expect breakages. That's why our plan is: Turn on early in the F18 cycle. Fix bugs which appear as they show up. If they are too many, revert to turned off.
I will post a longer annoucnement of this with suggested fixes to fedora-devel when we make the upload to turn this on for F18.
Thanks,
Lennart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/02/2012 04:25 PM, Lennart Poettering wrote:
On Mon, 02.04.12 20:58, Richard W.M. Jones (rjones@redhat.com) wrote: Heya,
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
Well, i'd claim this is not really user visible if implemented correctly. This is however visible to the developer.
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
Yes, large files need to be placed on /var/tmp, which is explained in the feature page.
- it doesn't support O_DIRECT
Well, all code using O_DIRECT should probably have a fallback to work without, anyway, and very likely has. O_DIRECT doesn't really make sense for tmpfs, it isn't really a feature that currently isn't supported and could be implemented, it is something that genuinly makes little sense for tmpfs...
- it doesn't support user extended attrs; and not very old kernels didn't
support any xattrs at all, meaning things like SELinux labels don't work
We do this change for F18, not for old Fedora with old kernels. SELinux labels work fine on tmpfs. User xattr patches have recently been posted on lkml, but indeed are not supported right now.
All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed.
But yes, this is absolutely true. We do expect breakages. That's why our plan is: Turn on early in the F18 cycle. Fix bugs which appear as they show up. If they are too many, revert to turned off.
I will post a longer annoucnement of this with suggested fixes to fedora-devel when we make the upload to turn this on for F18.
Thanks,
Lennart
I have been running with a tmpfs /tmp for years, without a problem. I have found the having /tmp be anything else that a tmpfs has caused me pain over the years with mislabeled files or files with the wrong UID.
Change to use a confined user or change the UID of a user suddenly X will not allow you to login, reboot does not fix the problem.
With tmpfs I get a nice clean /tmp on every boot.
Daniel J Walsh wrote: ...
I have been running with a tmpfs /tmp for years, without a problem. I have found the having /tmp be anything else that a tmpfs has caused me pain over the years with mislabeled files or files with the wrong UID.
Change to use a confined user or change the UID of a user suddenly X will not allow you to login, reboot does not fix the problem.
With tmpfs I get a nice clean /tmp on every boot.
I too have been pointing TMPDIR at a tmpfs directory (per-shell-distinct, even). The per-shell-distinct bit has exposed a few problems, where tools have expected $TMPDIR in one shell to be the same as $TMPDIR in another one, but nothing insurmountable.
On Monday, April 02, 2012 03:58:12 PM Richard W.M. Jones wrote:
#834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
What about forensics? Any reboot erases information that might have been needed to see what happened during a break in.
-Steve
On Mon, 02.04.12 16:55, Steve Grubb (sgrubb@redhat.com) wrote:
On Monday, April 02, 2012 03:58:12 PM Richard W.M. Jones wrote:
#834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
What about forensics? Any reboot erases information that might have been needed to see what happened during a break in.
/tmp is already volatile and cleaned up in regular intervals. The new clean-up on boot is just one tiny bit of additional clean-up.
Lennart
On Mon, 2 Apr 2012, Lennart Poettering wrote:
On Mon, 02.04.12 16:55, Steve Grubb (sgrubb@redhat.com) wrote:
What about forensics? Any reboot erases information that might have been needed to see what happened during a break in.
/tmp is already volatile and cleaned up in regular intervals. The new clean-up on boot is just one tiny bit of additional clean-up.
there is a big difference however with files in /tmp being around for 30 days, and the files being cleaned on a reboot, which might be necessary to get the system in a reliable enough state to do any forensics.
This also means a big change in user experience as many will be expecting things in /tmp to remain there for a while before being deleted even if the system is restarted or crashes.
Michael Young
* M A Young [02/04/2012 23:51] :
This also means a big change in user experience as many will be expecting things in /tmp to remain there for a while before being deleted even if the system is restarted or crashes.
The expectations of these 'many' (this really needs to be measured) run counter to the LSB recommendation for /tmp .
"Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted."
Emmanuel
On 04/02/2012 05:30 PM, M A Young wrote:
On Mon, 2 Apr 2012, Lennart Poettering wrote:
On Mon, 02.04.12 16:55, Steve Grubb (sgrubb@redhat.com) wrote:
What about forensics? Any reboot erases information that might have been needed to see what happened during a break in.
/tmp is already volatile and cleaned up in regular intervals. The new clean-up on boot is just one tiny bit of additional clean-up.
there is a big difference however with files in /tmp being around for 30 days, and the files being cleaned on a reboot, which might be necessary to get the system in a reliable enough state to do any forensics.
This also means a big change in user experience as many will be expecting things in /tmp to remain there for a while before being deleted even if the system is restarted or crashes.
Michael Young
I agree why does this have to be forced on everyone. Admins have the ability to do this now if they want to.
On Tue, Apr 3, 2012 at 8:38 AM, Steve Clark sclark@netwolves.com wrote:
On 04/02/2012 05:30 PM, M A Young wrote:
On Mon, 2 Apr 2012, Lennart Poettering wrote:
On Mon, 02.04.12 16:55, Steve Grubb (sgrubb@redhat.com) wrote:
What about forensics? Any reboot erases information that might have been needed to see what happened during a break in.
/tmp is already volatile and cleaned up in regular intervals. The new clean-up on boot is just one tiny bit of additional clean-up.
there is a big difference however with files in /tmp being around for 30 days, and the files being cleaned on a reboot, which might be necessary to get the system in a reliable enough state to do any forensics.
This also means a big change in user experience as many will be expecting things in /tmp to remain there for a while before being deleted even if the system is restarted or crashes.
Michael Young
I agree why does this have to be forced on everyone. Admins have the ability to do this now if they want to.
It's a default, not mandatory, admins will still be able to turn it off.
-J
-- Stephen Clark NetWolves Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
/tmp is a like a litter box. From a user perspective, I'm happy to have it emptied regularly, because clearly the cats don't clean up their own doodles. That one of the cats might think he's deposited something valuable that he'll come back for someday, is hilarious to me, as well as ridiculous.
My only concern about it being on tmpfs instead of on disk, is how big it could get, how much memory could be held hostage, until there's a reboot. I'd rather see it be both size and age limited (each item has a decay rate or something), so that it's evacuated more regularly than just between reboots - which could be months.
Chris Murphy
On 04/03/2012 10:31 AM, Chris Murphy wrote:
/tmp is a like a litter box. From a user perspective, I'm happy to have it emptied regularly, because clearly the cats don't clean up their own doodles. That one of the cats might think he's deposited something valuable that he'll come back for someday, is hilarious to me, as well as ridiculous.
My only concern about it being on tmpfs instead of on disk, is how big it could get, how much memory could be held hostage, until there's a reboot. I'd rather see it be both size and age limited (each item has a decay rate or something), so that it's evacuated more regularly than just between reboots - which could be months.
Indeed. I don't mind the cleaning of /tmp on reboots although I'm going to have to warn my users.
I've got two concerns about this change: * The (user|program) has to decide the location for temporary data based on its size. There have been arguments that everyone should have been using /var/tmp for ages but I'm not buying it. I suppose that made sense when there were separate /var and / partitions, but that hasn't been the case _ever_ for me on Linux and its been a long time since I did that on other platforms.
* The competition for space between things in /tmp and VM. When someone abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross.
Maybe I'm overreacting, but I've not seen a convincing case on why this has to be made the default rather than an opt-in situation. I certainly can't see this being a configuration I'd choose for my servers or any machine which may be memory limited.
Chris Murphy
Once upon a time, Brian Wheeler bdwheele@indiana.edu said:
- The competition for space between things in /tmp and VM. When someone
abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross.
First, tmpfs can be swapped. If you are swapping tmpfs files, how is that any worse than having /tmp on a disk? Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case).
I've been running with /tmp on tmpfs for several years, including on a number of servers, and I've never had any unusual problem related to it. I typically provision a little more swap on such systems, so that there's some room for spill-over.
Also, on servers where there are users with shell access, I'll typically limit the size of /tmp with an option in fstab (the default is RAM/2, which can be larger than I'd like). However, reading the feature page, this would be harder to do, since somebody's irrational fear of /etc/fstab is extending to /tmp. I think that's a bad idea, especially since the proposed feature creates yet another way to mount filesystems (systemd-"auto", /etc/fstab, and now a service for /tmp). Really? Two wasn't enough?
On Tue, 3 Apr 2012, Chris Adams wrote:
Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case).
That assumes your system is still functional enough to allow you to do that. In a low memory/high swap situation, which this could easily trigger, logging in and clearing the files could be very slow, and the login process could time out before you get logged in.
Michael Young
On Apr 3, 2012, at 9:48 AM, M A Young wrote:
On Tue, 3 Apr 2012, Chris Adams wrote:
Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case).
That assumes your system is still functional enough to allow you to do that. In a low memory/high swap situation, which this could easily trigger, logging in and clearing the files could be very slow, and the login process could time out before you get logged in.
If it's limited to 1/2 RAM*, even if it's the primary cause of a low memory situation it shouldn't cause thrashing. If it does cause thrashing, it's the source of it, and would happen if /tmp were on disk.
* I still think that default is excessive. But that's more impression than based on merit.
Once upon a time, M A Young m.a.young@durham.ac.uk said:
On Tue, 3 Apr 2012, Chris Adams wrote:
Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case).
That assumes your system is still functional enough to allow you to do that. In a low memory/high swap situation, which this could easily trigger, logging in and clearing the files could be very slow, and the login process could time out before you get logged in.
Again, if some file in /tmp is the problem, _that_ is liable to be what gets pushed to swap. At that point, you are back to something more or less equivalent to the current situation, with /tmp on disk. If a user can cause problems with that, they can already cause problems today.
On Apr 3, 2012, at 9:35 AM, Chris Adams wrote:
Once upon a time, Brian Wheeler bdwheele@indiana.edu said:
- The competition for space between things in /tmp and VM. When someone
abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross.
First, tmpfs can be swapped. If you are swapping tmpfs files, how is that any worse than having /tmp on a disk?
As long as it's swapped well before it starts to be a significant (i.e. not necessarily majority) contributor to a low-memory situation, fine.
Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case).
Using RAM, I'd be comfortable for /tmp using around 100MB, whereas for disk it might be 1GB. So, an order of magnitude difference in my tolerance level. Or on mobile, 1MB and 100MB, two orders of magnitude. Just depends.
Also, on servers where there are users with shell access, I'll typically limit the size of /tmp with an option in fstab (the default is RAM/2, which can be larger than I'd like).
1/2 of installed RAM? That just seems really, really excessive.
Chris Murphy
On 04/03/2012 11:35 AM, Chris Adams wrote:
Once upon a time, Brian Wheelerbdwheele@indiana.edu said:
- The competition for space between things in /tmp and VM. When someone
abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross.
First, tmpfs can be swapped. If you are swapping tmpfs files, how is that any worse than having /tmp on a disk? Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case).
I've been running with /tmp on tmpfs for several years, including on a number of servers, and I've never had any unusual problem related to it. I typically provision a little more swap on such systems, so that there's some room for spill-over.
Also, on servers where there are users with shell access, I'll typically limit the size of /tmp with an option in fstab (the default is RAM/2, which can be larger than I'd like). However, reading the feature page, this would be harder to do, since somebody's irrational fear of /etc/fstab is extending to /tmp. I think that's a bad idea, especially since the proposed feature creates yet another way to mount filesystems (systemd-"auto", /etc/fstab, and now a service for /tmp). Really? Two wasn't enough?
I have been doing this also but limiting how much space can be used in /etc/fstab with the size= option. To do away with being able to control this seems dumb.
On Tue, 03.04.12 12:30, Steve Clark (sclark@netwolves.com) wrote:
Also, on servers where there are users with shell access, I'll typically limit the size of /tmp with an option in fstab (the default is RAM/2, which can be larger than I'd like). However, reading the feature page, this would be harder to do, since somebody's irrational fear of /etc/fstab is extending to /tmp. I think that's a bad idea, especially since the proposed feature creates yet another way to mount filesystems (systemd-"auto", /etc/fstab, and now a service for /tmp). Really? Two wasn't enough?
I have been doing this also but limiting how much space can be used in /etc/fstab with the size= option. To do away with being able to control this seems dumb.
We are not doing away with this control. You can still configure it in fstab as you always did.
It's just that by default we don't have an entry there for tmpfs. If you have a line for /tmp there however, then yes, it takes precedence.
Lennart
On Tue, 2012-04-03 at 10:35 -0500, Chris Adams wrote:
Once upon a time, Brian Wheeler bdwheele@indiana.edu said:
- The competition for space between things in /tmp and VM. When someone
abuses space in /tmp (on purpose or not) then the system is going to start swapping and performance is going to suffer and the common response for fixing it will end up being 'just reboot'. That's just gross.
First, tmpfs can be swapped. If you are swapping tmpfs files, how is that any worse than having /tmp on a disk?
On my current desktop I have over a TB of /tmp disk, and ~3GB of free swap (~5GB is being used by web browsers/etc.). And I'm not dying to make swap any bigger so I can start swapping to death, instead of desktop apps. just crashing (this is bad enough already). Saying that my /tmp is currently "only" about ~500MB.
Dne 3.4.2012 16:31, Chris Murphy napsal(a):
My only concern about it being on tmpfs instead of on disk, is how big it could get, how much memory could be held hostage, until there's a reboot. I'd rather see it be both size and age limited (each item has a decay rate or something), so that it's evacuated more regularly than just between reboots - which could be months.
Cleanup of old files is already done, by systemd-tmpfiles. See /usr/lib/tmpfiles.d/tmp.conf.
Michal
Michal Schmidt wrote:
Cleanup of old files is already done, by systemd-tmpfiles. See /usr/lib/tmpfiles.d/tmp.conf.
Files, yes. Directories, no.
Due to a bug[1] in gvfs, I had over 100 old, empty directories in /tmp. Other apps may fill /tmp with directories, too, that will not be cleaned by any automatic process at this time.
Dne 3.4.2012 18:09, Michael Cronenworth napsal(a):
Michal Schmidt wrote:
Cleanup of old files is already done, by systemd-tmpfiles. See /usr/lib/tmpfiles.d/tmp.conf.
Files, yes. Directories, no.
It removes old directories too.
Due to a bug[1] in gvfs, I had over 100 old, empty directories in /tmp. Other apps may fill /tmp with directories, too, that will not be cleaned by any automatic process at this time.
The problem seems to be that something keeps touching these directories, so they never get old enough. The something needs to be identified and fixed.
Michal
On Tue, 03.04.12 08:31, Chris Murphy (lists@colorremedies.com) wrote:
My only concern about it being on tmpfs instead of on disk, is how big it could get, how much memory could be held hostage, until there's a reboot. I'd rather see it be both size and age limited (each item has a decay rate or something), so that it's evacuated more regularly than just between reboots - which could be months.
tmpfs by default are limited to 50% of the host RAM in size. Debian lowered this to 30% for /tmp. Whether it is 30% or 50% doesn't really matter too much, what does matter however is that tmpfs always comes with an enforced limit on size.
Since about always on Fedora /tmp has been cleaned up in regular intervals. Originally by tmpwatch, but these days by the tmpfiles logic.
Lennart
On 2 April 2012 14:55, Steve Grubb sgrubb@redhat.com wrote:
On Monday, April 02, 2012 03:58:12 PM Richard W.M. Jones wrote:
- #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
What about forensics? Any reboot erases information that might have been needed to see what happened during a break in.
I would guess it is a tossup. Depending on the security plan.. systems may want stuff in tmpfs to not allow for stuff to be around for a reboot (in the case where physical access after a reboot could compromise tokens and such). Other security plans required tmpfs to be turned off for forensics.
Many of the break-in kits though use /dev/shm already so they aren't going to be around after a reboot.
I would expect that any turn-on/turn-off of tmpfs would need to be configurable so that users who needed one or the other could get it.
On Mon, Apr 02, 2012 at 20:58:12 +0100, "Richard W.M. Jones" rjones@redhat.com wrote:
- it doesn't support O_DIRECT
I thought this was also true of ext4 with data journaling enabled.
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
The wiki page says: By implementing this we, by default, generate less IO on disks. This increases SSD lifetime, saves a bit of power and makes things a bit faster.
What about the memory pressure? with on-disk /tmp, the buffer cache prevents excessive writing if there's memory to spare, but the system still works when memory is used up. What happens with tmpfs? I think it will just grab and hold memory required for the /tmp filesystem, which is likely to cause swapping, which will hammer the disks even more. The lack of quota makes it potentially even worse.
Perhaps this should be a default only for systems with ample memory. Could it be a startup-time setting that is flipped back to on-disk /tmp if some sustained memory exhaustion is detected?
BTW, I thought that the buffer cache makes the speed argument mostly moot.
Am 03.04.2012 00:34, schrieb Przemek Klosowski:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
The wiki page says: By implementing this we, by default, generate less IO on disks. This increases SSD lifetime, saves a bit of power and makes things a bit faster.
What about the memory pressure? with on-disk /tmp, the buffer cache prevents excessive writing if there's memory to spare, but the system still works when memory is used up. What happens with tmpfs? I think it will just grab and hold memory required for the /tmp filesystem, which is likely to cause swapping, which will hammer the disks even more. The lack of quota makes it potentially even worse.
Perhaps this should be a default only for systems with ample memory. Could it be a startup-time setting that is flipped back to on-disk /tmp if some sustained memory exhaustion is detected?
+1
there are enough systems out there with not so much memory even in 2012 the most imprtant point are systems where /tmp is a own partition for many reasons - if there is a entry in /etc/fstab it MUST be honored
On Mon, Apr 02, 2012 at 06:34:59PM -0400, Przemek Klosowski wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
The wiki page says: By implementing this we, by default, generate less IO on disks. This increases SSD lifetime, saves a bit of power and makes things a bit faster.
What about the memory pressure? with on-disk /tmp, the buffer cache prevents excessive writing if there's memory to spare, but the system still works when memory is used up. What happens with tmpfs?
tmpfs contents are pageable, and will be swapped out if necessary.
Dave
On 04/02/2012 07:44 PM, Dave Jones wrote:
On Mon, Apr 02, 2012 at 06:34:59PM -0400, Przemek Klosowski wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
The wiki page says: By implementing this we, by default, generate less IO on disks. This increases SSD lifetime, saves a bit of power and makes things a bit faster.
What about the memory pressure? with on-disk /tmp, the buffer cache prevents excessive writing if there's memory to spare, but the system still works when memory is used up. What happens with tmpfs?
tmpfs contents are pageable, and will be swapped out if necessary.
I can't say that as a user (and sysadmin) I'm really thrilled with this. /tmp doesn't go away on reboots now so this is a biggish change from my point of view. There have been several times where I've dumped things in /tmp that I needed after a reboot. I really don't care what the LSB recommends in this case: this is a pretty big behavior change. The hand-wavy rule for "big files" going to /var/tmp and little things going to /tmp is also gross since its creating a distinction that really doesn't need to be there.
I've also dealt with sloppy users in the past that would write things to a tmpfs /tmp (on solaris) and not clean them up. Yes, its a programming issue, but I can't always control my users so instead of giving warnings that the disk was getting full the performance went to hell because it was swapping like crazy.
I've looked at the benefits page on the wiki and I'm not seeing any benefits to me. It seems more like someone that needed this solution would want to opt in to rather than forcing others to opt out of it.
Is there a reason why a symlink from /tmp -> /var/tmp and leaving /var/tmp on a real disk isn't sufficient for whatever is trying to be solved here?
On Tue, Apr 3, 2012 at 3:28 AM, Brian Wheeler bdwheele@indiana.edu wrote:
I can't say that as a user (and sysadmin) I'm really thrilled with this. /tmp doesn't go away on reboots now so this is a biggish change from my point of view.
That's what /tmp has always meant to be i.e a temporary filesystem that is not persistent across reboot. Relying on that has always been wrong it is perfectly fine to do delete everything in /tmp on reboot. There are a lot of places to store files that survive a reboot so not seeing what your problem here is.
Is there a reason why a symlink from /tmp -> /var/tmp and leaving /var/tmp on a real disk isn't sufficient for whatever is trying to be solved here?
That's broken /tmp should be cleaned up after reboots while /var/tmp should *not. So mixing them up is a bad idea.
I don't really get why people make so much fuss about a non issue really. 99,99% of the users won't even notice that anything changed at all.
Am 03.04.2012 09:17, schrieb drago01:
I don't really get why people make so much fuss about a non issue really. 99,99% of the users won't even notice that anything changed at all.
for this 99.9% the current behavior is also good enough if they do not notice any change
the other 0.1% are servers where /tmp is a own partition or for virtual machines often even a own virtual disk where as example mysqld writes temp-files for many operations require a temp-table or vmware put memory mapped files
these are actions often require a lot of disk space and /tmp was set up as own virtual disk to NOT use rootfs
On 04/03/2012 04:50 AM, Reindl Harald wrote:
Am 03.04.2012 09:17, schrieb drago01:
I don't really get why people make so much fuss about a non issue really. 99,99% of the users won't even notice that anything changed at all.
for this 99.9% the current behavior is also good enough if they do not notice any change
the other 0.1% are servers where /tmp is a own partition or for virtual machines often even a own virtual disk where as example mysqld writes temp-files for many operations require a temp-table or vmware put memory mapped files
these are actions often require a lot of disk space and /tmp was set up as own virtual disk to NOT use rootfs
There's nothing stopping you from setting things up this way if that's what you need.
Jaroslav Skarvada wrote:
Any numbers to support these claims?
I have numbers to *dispute* these claims.
(server with Apache, koji, LDAP)$ sudo du -sh /tmp 396K /tmp
(work desktop)$ sudo du -sh /tmp 352K /tmp
(server with Apache, bugzilla, wiki)$ sudo du -sh /tmp 312K /tmp
(home desktop with SSDs in RAID0)$ sudo du -sh /tmp 1.2M /tmp
I'm really not worried about IO or SSD life from /tmp usage.
Hi.
On Fri, 06 Apr 2012 09:20:46 -0500, Michael Cronenworth wrote
I have numbers to *dispute* these claims.
(server with Apache, koji, LDAP)$ sudo du -sh /tmp 396K /tmp
(work desktop)$ sudo du -sh /tmp 352K /tmp
(server with Apache, bugzilla, wiki)$ sudo du -sh /tmp 312K /tmp
(home desktop with SSDs in RAID0)$ sudo du -sh /tmp 1.2M /tmp
I'm really not worried about IO or SSD life from /tmp usage.
I see what you're trying to say, and I tend to agree with you, but the amount of space consumed at any one point in time does not reflect the amount of IO going on on that file system.
Am 06.04.2012 16:38, schrieb Ralf Ertzinger:
Hi.
On Fri, 06 Apr 2012 09:20:46 -0500, Michael Cronenworth wrote
I have numbers to *dispute* these claims.
(server with Apache, koji, LDAP)$ sudo du -sh /tmp 396K /tmp
(work desktop)$ sudo du -sh /tmp 352K /tmp
(server with Apache, bugzilla, wiki)$ sudo du -sh /tmp 312K /tmp
(home desktop with SSDs in RAID0)$ sudo du -sh /tmp 1.2M /tmp
I'm really not worried about IO or SSD life from /tmp usage.
I see what you're trying to say, and I tend to agree with you, but the amount of space consumed at any one point in time does not reflect the amount of IO going on on that file system.
the IO on /tmp in most worksloads is practically meaningless
in workloads where it becomes meaningfull you do NOT want to have this hughe data in tmpfs because it is too large
there is a reason why applications are creating temp FILES instead store anything in the memory
Ralf Ertzinger wrote:
I see what you're trying to say, and I tend to agree with you, but the amount of space consumed at any one point in time does not reflect the amount of IO going on on that file system.
So I need to invest a week or two setting up blktraces across multiple application loads and come back with a series of graphs and charts to show how little IO is done in /tmp?
Why does the Feature Owner get a pass from a simple statement of "less IO" and I have to spend a lot of time and effort to dispute it?
Hi.
On Fri, 06 Apr 2012 09:41:08 -0500, Michael Cronenworth wrote
So I need to invest a week or two setting up blktraces across multiple application loads and come back with a series of graphs and charts to show how little IO is done in /tmp?
As I said, I think you're right in general wrt the amount of IO on /tmp (namely, little enough). Just that the numbers you listed are unable to support that hypothesis on their own because they measure the wrong thing.
On Apr 6, 2012, at 8:20 AM, Michael Cronenworth wrote:
I'm really not worried about IO or SSD life from /tmp usage.
I think the premise behind the coddling of SSD shouldn't be a consideration. If if true, it won't be true much longer. Are the advocates of SSD coddling suggesting we disable file system journalling for the benefaction of poor sensitive SSD's life span benefits?
Chris Murphy
Richard W.M. Jones wrote:
Actually I think this is a good feature, but ...
I'm unsure about whether this makes sense for new installs or not, but I feel my objection in https://fedoraproject.org/wiki/Talk:Features/tmp-on-tmpfs was not taken into account at all. :-/ Forcing this change on upgrades will leave users with wasted disk space they cannot easily reclaim. (For us technical users, reclaiming it will be complicated, for non-technical users, it will be impossible.)
Kevin Kofler
On Tue, Apr 3, 2012 at 5:10 AM, Kevin Kofler kevin.kofler@chello.at wrote:
Richard W.M. Jones wrote:
Actually I think this is a good feature, but ...
I'm unsure about whether this makes sense for new installs or not, but I feel my objection in https://fedoraproject.org/wiki/Talk:Features/tmp-on-tmpfs was not taken into account at all. :-/ Forcing this change on upgrades will leave users with wasted disk space they cannot easily reclaim. (For us technical users, reclaiming it will be complicated, for non-technical users, it will be impossible.)
We could just make anaconda remove everything in /tmp ... done.
drago01 wrote:
We could just make anaconda remove everything in /tmp ... done.
First of all, renaming it as Simo Sorce suggested makes more sense.
But secondly, what you both miss is that not everyone upgrades using Anaconda, there's also plain yum. Seeing more and more black magic getting added to Anaconda to deal with pointless arcane incompatible file system changes really makes me cringe.
Kevin Kofler
On Wed, Apr 04, 2012 at 11:51:08AM +0200, Kevin Kofler wrote:
drago01 wrote:
We could just make anaconda remove everything in /tmp ... done.
First of all, renaming it as Simo Sorce suggested makes more sense.
But secondly, what you both miss is that not everyone upgrades using Anaconda, there's also plain yum. Seeing more and more black magic getting
Fot those scenarios, there is wiki page.
On 04/04/2012 01:36 PM, Tomasz Torcz wrote:
On Wed, Apr 04, 2012 at 11:51:08AM +0200, Kevin Kofler wrote:
drago01 wrote:
We could just make anaconda remove everything in /tmp ... done.
First of all, renaming it as Simo Sorce suggested makes more sense.
But secondly, what you both miss is that not everyone upgrades using Anaconda, there's also plain yum. Seeing more and more black magic getting
Fot those scenarios, there is wiki page.
That's more a weak excuse but a solution.
On Tue, 2012-04-03 at 05:10 +0200, Kevin Kofler wrote:
Richard W.M. Jones wrote:
Actually I think this is a good feature, but ...
I'm unsure about whether this makes sense for new installs or not, but I feel my objection in https://fedoraproject.org/wiki/Talk:Features/tmp-on-tmpfs was not taken into account at all. :-/ Forcing this change on upgrades will leave users with wasted disk space they cannot easily reclaim. (For us technical users, reclaiming it will be complicated, for non-technical users, it will be impossible.)
Can't this be easily resolved by renaming /tmp ->/old-tmp at upgrade time ?
Simo.
On 2 April 2012 20:58, Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Does this have any implications for polyinstantiated tmp directories? As far as I can see, it should cause no problems as pam_namespace has an option for tmpfs tmp directories. But I thought it worth asking.
Jonathan.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/04/2012 04:31 AM, Jonathan Underwood wrote:
On 2 April 2012 20:58, Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Does this have any implications for polyinstantiated tmp directories? As far as I can see, it should cause no problems as pam_namespace has an option for tmpfs tmp directories. But I thought it worth asking.
Jonathan.
I don't see how. Since polycinstantiated tmp dirs are just being mounted over /tmp. Either as tmpfs or a physical directory, or a subdir of /tmp
On Wed, 04.04.12 09:31, Jonathan Underwood (jonathan.underwood@gmail.com) wrote:
On 2 April 2012 20:58, Richard W.M. Jones rjones@redhat.com wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Does this have any implications for polyinstantiated tmp directories? As far as I can see, it should cause no problems as pam_namespace has an option for tmpfs tmp directories. But I thought it worth asking.
It should just continue to work as it always did.
Lennart
On Mon, Apr 02, 2012 at 08:58:12PM +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
+1
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
it's very limited in space compared to a real disk
it doesn't support O_DIRECT
it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work
- quota, the generic tmpfs problem...
Karel
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
This is the reason why I refused having /tmp as tmpfs (or even as a separate partition) few months ago. Has anybody tried to use e.g. Brasero with it? Well, if you are burning a DVD, Brasero needs about 4 GB on /tmp -- not enough space in RAM or wasting a lot of disk space on having such big /tmp partition that is most of the time unused. Yes, you can tell Brasero to use some other space, but it obviously relies on volatility of the /tmp and doesn't clean after itself. I'm quite sure this is not only the case of Brasero.
On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
This is the reason why I refused having /tmp as tmpfs (or even as a separate partition) few months ago. Has anybody tried to use e.g. Brasero with it? Well, if you are burning a DVD, Brasero needs about 4 GB on /tmp -- not enough space in RAM or wasting a lot of disk space on having such big /tmp partition that is most of the time unused. Yes, you can tell Brasero to use some other space, but it obviously relies on volatility of the /tmp and doesn't clean after itself. I'm quite sure this is not only the case of Brasero.
We should file bugs on those issues and add them to some tracker bug, which will be created for tmpfs related issues. Brasero, k3b and applications for scanning will probably need patches. I hope some of these bugs were fixed, because Debian already have tmpfs on /tmp.
Marcela
On 04/06/2012 01:47 PM, Marcela Mašláňová wrote:
On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
This is the reason why I refused having /tmp as tmpfs (or even as a separate partition) few months ago. Has anybody tried to use e.g. Brasero with it? Well, if you are burning a DVD, Brasero needs about 4 GB on /tmp -- not enough space in RAM or wasting a lot of disk space on having such big /tmp partition that is most of the time unused. Yes, you can tell Brasero to use some other space, but it obviously relies on volatility of the /tmp and doesn't clean after itself. I'm quite sure this is not only the case of Brasero.
We should file bugs on those issues and add them to some tracker bug, which will be created for tmpfs related issues.
That a lost fight, because one of /tmp's primary purposes is to temporarily store almost arbitrarily huge amounts of data, instead of storing them in memory.
This would mean, to prepare tmpfs for this use-case, you'd have to make swap similarly large as /tmp is without tmpfs.
Brasero, k3b and applications for scanning will probably need patches.
No idea, what you are intending to do. These apps use huge amounts of temporary data. Amounts of data, its devs probably considered to be too big to be stored in memory and thus decided to store them in /tmp. A fully legitimate use case.
Also consider that the required size of data in /tmp can very dynamic and be very different in different use-cases. This is a fact people often do not notice causes unexpected surprises to them (e.g. when launching some heavy-weight compile job).
I hope some of these bugs were fixed,
Are you seriously calling storing temporary files into /tmp to be bugs?
Ralf
Am 06.04.2012 14:58, schrieb Ralf Corsepius:
Brasero, k3b and applications for scanning will probably need patches.
No idea, what you are intending to do. These apps use huge amounts of temporary data. Amounts of data, its devs probably considered to be too big to be stored in memory and thus decided to store them in /tmp. A fully legitimate use case.
Also consider that the required size of data in /tmp can very dynamic and be very different in different use-cases. This is a fact people often do not notice causes unexpected surprises to them (e.g. when launching some heavy-weight compile job).
I hope some of these bugs were fixed,
Are you seriously calling storing temporary files into /tmp to be bugs?
this si another story where i do not understand the intention of developers by making useless changes for non-broken things
it is NOT a bug of any application using /tmp for large files
it is a bug in the distribution put /tmp as default in RAM why do people believe it is a solution to "fix" applications storing their temp-files below /var/tmp
/var/tmp is for data you expect to be here ven after reboot congratulations to the idea store temporary iso-images there with the effect the systemdisk of many normal users starts to get full becuse "tmpwatch" does not clean up them
everybody who thinks /tmp should be a tmpfs and beeing sure he has enough RAm for this can do it all the time in fstab
what is the benefit/improvement making this as default? will we start finally tell people using eclipse and firefox on notebooks with 4 GB of RAM that this is not enough for a modern linux-system because with the additional memory pressure their machines starting to get unuseable?
Reindl Harald wrote:
Am 06.04.2012 14:58, schrieb Ralf Corsepius:
Brasero, k3b and applications for scanning will probably need patches.
No idea, what you are intending to do. These apps use huge amounts of temporary data. Amounts of data, its devs probably considered to be too big to be stored in memory and thus decided to store them in /tmp. A fully legitimate use case.
Also consider that the required size of data in /tmp can very dynamic and be very different in different use-cases. This is a fact people often do not notice causes unexpected surprises to them (e.g. when launching some heavy-weight compile job).
I hope some of these bugs were fixed,
Are you seriously calling storing temporary files into /tmp to be bugs?
this si another story where i do not understand the intention of developers by making useless changes for non-broken things
it is NOT a bug of any application using /tmp for large files
it is a bug in the distribution put /tmp as default in RAM why do people believe it is a solution to "fix" applications storing their temp-files below /var/tmp
/var/tmp is for data you expect to be here ven after reboot congratulations to the idea store temporary iso-images there with the effect the systemdisk of many normal users starts to get full becuse "tmpwatch" does not clean up them
everybody who thinks /tmp should be a tmpfs and beeing sure he has enough RAm for this can do it all the time in fstab
what is the benefit/improvement making this as default? will we start finally tell people using eclipse and firefox on notebooks with 4 GB of RAM that this is not enough for a modern linux-system because with the additional memory pressure their machines starting to get unuseable?
A big +1 to both Ralf and Harald. The more I think about the change, the less I like it (and I never got the point in the first place). K3b is most definitely going to be broken by it. Having to change /tmp to /var/tmp almost everywhere is not helpful, plus if /var/tmp indeed doesn't and won't get cleaned, that's also a problem. It might be more helpful to have the tmpfs directory use a new namespace (/tmp/volatile or something like that) instead of the existing and heavily-used /tmp.
Kevin Kofler
On 04/06/2012 02:58 PM, Ralf Corsepius wrote:
On 04/06/2012 01:47 PM, Marcela Mašláňová wrote:
On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
This is the reason why I refused having /tmp as tmpfs (or even as a separate partition) few months ago. Has anybody tried to use e.g. Brasero with it? Well, if you are burning a DVD, Brasero needs about 4 GB on /tmp -- not enough space in RAM or wasting a lot of disk space on having such big /tmp partition that is most of the time unused. Yes, you can tell Brasero to use some other space, but it obviously relies on volatility of the /tmp and doesn't clean after itself. I'm quite sure this is not only the case of Brasero.
We should file bugs on those issues and add them to some tracker bug, which will be created for tmpfs related issues.
That a lost fight, because one of /tmp's primary purposes is to temporarily store almost arbitrarily huge amounts of data, instead of storing them in memory.
This would mean, to prepare tmpfs for this use-case, you'd have to make swap similarly large as /tmp is without tmpfs.
Brasero, k3b and applications for scanning will probably need patches.
No idea, what you are intending to do. These apps use huge amounts of temporary data. Amounts of data, its devs probably considered to be too big to be stored in memory and thus decided to store them in /tmp. A fully legitimate use case.
Also consider that the required size of data in /tmp can very dynamic and be very different in different use-cases. This is a fact people often do not notice causes unexpected surprises to them (e.g. when launching some heavy-weight compile job).
I hope some of these bugs were fixed,
Are you seriously calling storing temporary files into /tmp to be bugs?
Ralf
I tried to explain position of FESCo, but I'd rather leave it to someone who likes this change ;-)
Marcela
On Fri, 2012-04-06 at 14:58 +0200, Ralf Corsepius wrote:
On 04/06/2012 01:47 PM, Marcela Mašláňová wrote:
On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
This is the reason why I refused having /tmp as tmpfs (or even as a separate partition) few months ago. Has anybody tried to use e.g. Brasero with it? Well, if you are burning a DVD, Brasero needs about 4 GB on /tmp -- not enough space in RAM or wasting a lot of disk space on having such big /tmp partition that is most of the time unused. Yes, you can tell Brasero to use some other space, but it obviously relies on volatility of the /tmp and doesn't clean after itself. I'm quite sure this is not only the case of Brasero.
We should file bugs on those issues and add them to some tracker bug, which will be created for tmpfs related issues.
That a lost fight, because one of /tmp's primary purposes is to temporarily store almost arbitrarily huge amounts of data, instead of storing them in memory.
This is the key overlooked fact.
-- Vratislav Podzimek
On Apr 6, 2012, at 8:03 AM, Vratislav Podzimek wrote:
That a lost fight, because one of /tmp's primary purposes is to
temporarily store almost arbitrarily huge amounts of data, instead of storing them in memory.
This is the key overlooked fact.
What happens to /tmp on tmpfs when real memory and swap are completely consumed? I think the key overlooked fact is the possibility some application asks for a lot more /tmp space than is ever reserved for swap. Example:
I'd expect Brisera to produce an ~9GB temp file when burning a fully consumed dual-layer DVD. Incorrect assumption? Minimum requirements for Fedora 16, 1152MB RAM. That translates into what default for swap space? Is this at least 4GB, or whatever the minimum amount of swap needed for tmpfs when full to overflow to?
Does anyone know what the behavior of Scribus, GIMP, Cinelerra, etc. are when it comes to temp space requirements? I could see GIMP arbitrarily want multiple gigabytes of space, well beyond physical RAM plus that reserved for swap space.
Chris Murphy
Am 06.04.2012 20:50, schrieb Chris Murphy:
On Apr 6, 2012, at 8:03 AM, Vratislav Podzimek wrote:
That a lost fight, because one of /tmp's primary purposes is to
temporarily store almost arbitrarily huge amounts of data, instead of storing them in memory.
This is the key overlooked fact.
What happens to /tmp on tmpfs when real memory and swap are completely consumed? I think the key overlooked fact is the possibility some application asks for a lot more /tmp space than is ever reserved for swap. Example:
I'd expect Brisera to produce an ~9GB temp file when burning a fully consumed dual-layer DVD. Incorrect assumption? Minimum requirements for Fedora 16, 1152MB RAM. That translates into what default for swap space? Is this at least 4GB, or whatever the minimum amount of swap needed for tmpfs when full to overflow to?
Does anyone know what the behavior of Scribus, GIMP, Cinelerra, etc. are when it comes to temp space requirements? I could see GIMP arbitrarily want multiple gigabytes of space, well beyond physical RAM plus that reserved for swap space.
the developers of this "feature" try to explain us that applications should stop using /tmp and put their stuff in /var/tmp to make the "feature" possible
as longer i think about the idea having /tmp in memory as default as lesser sense this idea is making for me
however, as long my enry in /etc/fstab is honored all the users with default setups does not bother me, but that does not make things better for the overall quality of the distribution
On 04/06/2012 02:50 PM, Chris Murphy wrote:
What happens to /tmp on tmpfs when real memory and swap are completely consumed?
I assume it would get an -ENOSPC...but with RAM and swap being full I don't expect that the end user would ever see the error before the machine bogged down to the point of being unusable. Of course, I could be wrong.
On Apr 6, 2012, at 1:02 PM, Brian Wheeler wrote:
On 04/06/2012 02:50 PM, Chris Murphy wrote:
What happens to /tmp on tmpfs when real memory and swap are completely consumed?
I assume it would get an -ENOSPC...but with RAM and swap being full I don't expect that the end user would ever see the error before the machine bogged down to the point of being unusable. Of course, I could be wrong.
It kinda sounds to me like /tmp on tmpfs is a solution in search of a problem.
Chris Murphy
On 04/06/2012 07:47 AM, Marcela Mašláňová wrote:
On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
- #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr,
17:40:06)
- AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I think this is a good feature, but ...
The feature page is wrong about "The user experience should barely change. This is mostly a low-level change that has little visibility to the user."
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
This is the reason why I refused having /tmp as tmpfs (or even as a separate partition) few months ago. Has anybody tried to use e.g. Brasero with it? Well, if you are burning a DVD, Brasero needs about 4 GB on /tmp -- not enough space in RAM or wasting a lot of disk space on having such big /tmp partition that is most of the time unused. Yes, you can tell Brasero to use some other space, but it obviously relies on volatility of the /tmp and doesn't clean after itself. I'm quite sure this is not only the case of Brasero.
We should file bugs on those issues and add them to some tracker bug, which will be created for tmpfs related issues. Brasero, k3b and applications for scanning will probably need patches. I hope some of these bugs were fixed, because Debian already have tmpfs on /tmp.
Marcela
I'm still not convinced that there's any actual benefit from this change for 99% of the users. Filing bugs on anything that uses /tmp because it _might_ make a file which is inconveniently large seems more like busy work than actually solving a problem.
In the FHS /tmp is only defined as a place for temporary files which may not be preserved between reboots. There is nothing about size and this change puts an additional limitation on /tmp which isn't codified anywhere and will vary greatly from installation to installation -- based on memory/swap size.
Additionally, if programs are leaving large temp files and not cleaning them up, then they're putting them in /var/tmp where it will take even longer to clean them up automatically.
Brian
Richard W.M. Jones wrote:
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
Adobe Flash uses /tmp to store video stream data. How are distributions who have implemented this handling large (say movie) Flash video streams? I could easily see /tmp being exhausted by a 60 minute or longer 1080p stream (2gb+).
I'd rather not get into the politics about Flash so please limit discussion to the former paragraph.
On Tue, Apr 10, 2012 at 3:31 PM, Michael Cronenworth mike@cchtml.com wrote:
Richard W.M. Jones wrote:
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
Adobe Flash uses /tmp to store video stream data.
s/uses/used to/ ... it stopped doing that a while ago.
On Tue, Apr 10, 2012 at 07:36:39PM +0200, drago01 wrote:
On Tue, Apr 10, 2012 at 3:31 PM, Michael Cronenworth mike@cchtml.com wrote:
Richard W.M. Jones wrote:
tmpfs is different in a number of important ways:
- it's very limited in space compared to a real disk
Adobe Flash uses /tmp to store video stream data.
s/uses/used to/ ... it stopped doing that a while ago.
It still does, it just unlinks them. They still take up space.