Re: /tmp as tmpfs and consequence for imaging software
On Sat, Nov 12, 2011 at 11:25:12PM +0100, Josselin Mouette wrote:
> Le samedi 12 novembre 2011 à 23:12 +0100, Samuel Thibault a écrit :
> > Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a écrit :
> > > You need to increase the swap size by the amount you'd use for /tmp.
> >
> > Well, the idea of such case is precisely to *not* use swap, but real
> > disks. Such software already know how to manage its memory and
> > disk-backed memory (thusly stored in /tmp)
>
> Practically speaking, the only significant difference is that files are
> not forced to disk as early.
That, and you don't have to do umpteen metadata writes (including barriers!)
for every file written to. Real filesystems work with the assumption that
both the files need to be durable and the filesystem itself must be
consistent even after a crash, including caring about the disk controller
"maliciously" reordering writes. We're speaking of ~ seven seeks + writes
for creating an one-block file. Log-structured filesystems might not have
such journal churn but are still worse than tmpfs.
> Otherwise, if you have a large enough swap, pages of a file on a tmpfs
> that are not used enough will be swapped. And pages of a file on a
> regular filesystem that are used enough will be kept in the buffer cache.
In other words, tmpfs never[1] performs worse than an actual filesystem.
Usually the files won't be ever actually written to the disk, and if they
will, tmpfs will work equivalently (anonymous vs file-backed pages), minus
crash consistency costs.
There's a configuration issue caused by taking space from a different pool,
though.
[1]. Currently, if there are multiple concurrent writers of large files,
there will be fragmentation smart real filesystems have workarounds for.
This could be avoided by hinting the kernel that if it swaps down a block,
it should consider the next block of the same file rather than strictly
following LRU order. Such logic is far simpler than what real filesystems
have to do.
--
1KB // Yo momma uses IPv4!
Reply to: