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

Steve Clark sclark at netwolves.com
Thu May 31 15:46:21 UTC 2012

On 05/31/2012 08:57 AM, Roberto Ragusa wrote:
> 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.

Stephen Clark
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120531/4acae3ac/attachment-0001.html>

More information about the devel mailing list