Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/31/2012 12:55 PM, Ralf Corsepius wrote:
> On 05/31/2012 12:45 PM, Pádraig Brady wrote:

>> Now /var/tmp should be "more persistent" which we don't need,
> Correct, using /var/tmp is wrong and a mistake.
> 
> IMO, advising people to modify their code to using /var/tmp instead of /tmp is absurd and evidence of ignorance towards traditional use of /tmp and the FHS.
> 
>> So I'll patch sort to default to /var/tmp rather than /tmp.
> This would mean introducing a bug.

As far as I know:

/tmp is for large data with no expectation of reboot persistence
/var/tmp is for large data with expectation of reboot persistence

tmpfs is for *small* data, so not a good choice for /tmp,
it is certainly optimal for /var/run /var/lock and so on.

I suppose that an additional small-tmp (e.g. /tmpram) could
be useful for some programs currently using tmp for very
small files. But these programs should be patched to deviate
from a traditional Unix convention.
As small (and short lived) files are equally fast on tmpfs
or disk based /tmp, the whole effort is probably pointless.

What would be a really good solution is the ability to specify
very long timeouts for the VM write-back of a normal filesystem.
Having /tmp dirty data in memory for 2 hours (and immune to normal sync
commands) is the perfect approach.
Have RAM? Use RAM. RAM pressure? Becomes a normal disk.
(letting tmpfs swap is NOT the actually same thing, and I
doubt you can set tmpfs much bigger than real RAM)

It is quite easy to come up with use-cases where a small /tmp
will be a problem.

- any kind of temporary unpack/copy pattern, such as entering
a tar.gz with mc, unpacking of installation files for (mostly
proprietary) packages, ...

- vmware uses /tmp/ram0 (immediately unlinked) as guest RAM
backstore

- I personally use /tmp for large files (including ISOs of
DVD I want to burn and delete); maybe I'm the only one doing
that...

- I just discovered that my /tmp is currently 3.2GiB. The
majority of the space is for /tmp/kde-myusername/konsole*.tmp
(700MiB+520MiB+364MiB+305MiB+117MiB+....), as I run konsole
with unlimited scrollback buffer and some shells have easily
been open for weeks.

If the feature is implemented and activated by default,
I will just turn it off and live happy. It will just be one more
thing in the growing list of defaults that should have never been
changed.
But be prepared to more than "one or two" future bugs of the
kind "Oracle can't be installed", "my backup program fails",
"the machine slows down to a crawl and only a reboot fixes it", ...

Best regards.
-- 
   Roberto Ragusa    mail at robertoragusa.it
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux