Re: Moving /tmp to tmpfs makes it useful
2012/5/30 Vincent Lefevre wrote:
>>> So what? If you write to a normal file system, it goes into the page
>>> cache, which is pretty much the same as writing into tmpfs. In both
>>> cases if you have swap configured, the data will get pushed to disk;
>>
>> That's not at all the same, the page cache is more temporary, it's getting
>> flushed to disk pretty quick if memory is tight (presumably) but in the same
>> situation using tmpfs going to swap is surely going to be more disruptive?
>
> Why wouldn't there be a FS option to have a different policy for
> specific directories, like /tmp? e.g. avoid write-back to disk
> except when needed (because of lack of RAM). In such a way, the
> behavior would be similar to tmpfs, without the restriction on
> the tmpfs size, i.e. this would be more flexible for the user.
Well, even being better than tmpfs, this idea still has downsides. Kernel
fs cache is smart. It stores the files (not exactly files, but who cares)
that are the most useful. When you create tmpfs, or when you set such
"FS option" (keep /tmp files in RAM as long as there's free RAM for them)
you eat cache memory. Meaning, you store /tmp files in cache even when
they're not used, so kernel cannot use that memory to store some useful
files. This increases I/O and makes the system slower.
But, anyway, directory-specific options are not impossible. Theoretically
one could write a special [FUSE] filesystem just for that case. I was
already thinking about doing something like aufs- or unionfs-mount of a
small tmpfs (i.e. 10MB) backed up by real disk /tmp. That way small files
could remain in RAM while large files that don't fit there would go to
real cached disk. I was even thinking about patching unionfs-fuse to
support such a case. I just could not find a reason to start doing that.
I mean, why would people want that feature? The only case I can think of:
people with notebooks having SSD-disks, who want to reduce number of disk
writes. And they usually want to do that for the whole disk, not just
/tmp. There're a lot of ways to do that (starting from tuning kernel
vm/dirty_*_centisecs options, up to a paranoid setup that does no writes
at all). And since most writes are not limited to /tmp it's pointless
to optimize just a /tmp for it.
> BTW, I wish there were a document summarizing all these discussions.
I'm going to write some summary. Just waiting to hear all the opinions.
--
Serge
Reply to: