Re: /tmp as tmpfs and consequence for imaging software

[Goswin von Brederlow <goswin-v-b@web.de>]

Russell Coker <russell@coker.com.au> writes:

> On Wed, 16 Nov 2011, Goswin von Brederlow <goswin-v-b@web.de> wrote:
>> With a filesystem it will write the dirty buffers to disk in the
>> background and then drop the clean pages from the cache quite
>> consistently. This leaves the code involved with moving the mouse
>> pointer alone and functioning smoothly.
>
> That's not what I have observed.
>
> The command "mv /mnt/usb/* /mnt/nfs" can cause X related stuff to be swapped 
> out and the mouse pointer to freeze.  It happens to me repeatedly running 
> Unstable with kernel 3.0.0-2.

True. I do see the same thing with writing to NFS. The cache gets
quickly filled with dirty pages, the network can't (or simply doesn't
for some reason) keep up and then linux runs into the out-of-memory path
and starts swapping or otherwise blocks. But I've only seen that with NFS.

> On Wed, 16 Nov 2011, Goswin von Brederlow <goswin-v-b@web.de> wrote:
>> Having /tmp on / would quickly degrade performance as the filesystems
>> free space becomes fragmented over time. So if you end up with a tmpfs
>> for /tmp on such a system you already did install your systems wrong for
>> your use case under the old setup. So only suboptimal configurations are
>> hurt by defaulting to tmpfs. :)
>
> Could you please point me to a reference about some research on ext3/4 
> fragmentation supporting this claim?

Can't give you any references but any research on fragmentation should
show you that if you mix short term and long term data then you will get
pices of the long term data stuck all over the place reducing the size
of continious blocks that are free.

>From personal experience I've managed to degrade an ext3 filesystem to
the point where reading of data sustained barely over 100KB/s by running
rtorrent with lots of downloads on it for a few month and always above
90% full.

MfG
        Goswin