Re: Lets (eventually) find a good solution for /tmp
Don is right.
I'd like to step up a level and think about the situation.
The real issue here is that having /tmp be just another directory in a
writable partition filesystem, like / or /home or whatever, means that
/tmp gets all the associated properties. One such property (A) is
that files can be large and can bleed off to disk smoothly without
thrashing the system, both of which are problems with tmpfs. On the
other hand, another property (B) is that a great deal of effort is
going into ensuring that files get written to disk in a timely
fashion, that data and metadata survives crashes, and that structures
on disk are consistent, up-to-date, and if necessary, quick to check.
We want /tmp to have (A), but it need not have (B).
So this is a technical question. Can we implement a filesystem which
provides properties A, but which (C) has zero data surviving after a
crash or umount, and takes advantage of property C to make things
faster. This seems like a much easier problem than the problems that
journaling filesystems and their ilk solve. But even though it may be
an easy problem, to my knowledge, no one has implemented a solution.
IDEAS
One thought would be to make a fuse filesystem which keeps small files
in the fuse process itself (like tmpfs) and puts big files on a big
filesystem but *unlinks* the files so their only reference is via an
open handle held by the fuse process itself. The files are thus
backed on disk as usual, and can be large, but when the fuse process
dies *bam* they're gone, and the usual recovery mechanisms scavenge
their space after a crash.
Another thought would be to hack tmpfs to keep only big files in some
backing filesystem, perhaps using handles to unlinked files as above,
thus having the advantages of tmpfs for small files while also
handling large files well.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
Reply to: