/tmp/*

Richard Lightman richard at nezumi.plus.com
Sat Oct 26 06:42:26 PDT 2002


* Bill Maltby - LFS Related <lfsbill at wlmcs.com> [2002-10-26 14:27]:
> On Sat, 26 Oct 2002, Ian Molton wrote:
> >
> >I have a gig of swap, but still, I like to have /tmp on disc...
> 
> However, it does have the *potential* to make things run faster. Consider
> that a great deal of ram is used for buffers and cache. Unfortunately,
> much of this is idle due to the long times before the vm throws them
> out. If you have tmpfs that is *reasonably* active, there is the
> possibility that unneeded buffers and cache will be used for the tmpfs
> files and reduce head movement. If the tmpfs activity is *too* high, then
> there may still be some gain because swap access should be a tad faster
> than normal fs access, although head movement could be a little higher
> than in the ideal scenario.
> 
I am not so sure about a speed advantage. Perhaps against ext2 or ext3,
but not compared to something with a modern design like reiser or xfs.
If there is a speed advantage, it would be more likely to come from
files that are created and deleted so fast that they never need to hit
the disc.

> Of course, all depends on the activity profile because we could get into
> "thrashing" situations under extreme conditions.
> 
If you are thrashing tmpfs, then you would be thrashing a real
filesystem.

> What would be ideal is automatic placement of small /tmp files on the
> tmpfs and "large" ones on a real partition.
> 
Small, or large, it makes no difference. I compile everything in tmpfs.
The only thing you cannot do (without a kernel patch) is use it for
a loop back file system.

> Is it me, or didn't this come up way-back-when?
> 
Yes it did.
The only real argument presented against it was that some users might
expect /{,var/}tmp to retain contents over a reboot.

Richard

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list