List Archive: gentoo-amd64
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Tue, July 12, 2005 1:51 pm, Kyle Liddell said:
> but will help when you realize "oh no, I need another 500mb
> for /var/tmp/portage"...
On my system I have /tmp and /var/tmp mounted as tmpfs. My philosophy is
that nothing important should be in there anyway, and if I'm buliding I
really don't care whether the files being compiled are ever committed to
disk. The advantage of tmpfs is that if there is no need to free up RAM,
your build directory will never get written to disk at all - just the
final merged files. Of course, you'll need a few GB of RAM/swap to
accomplish this, and when doing the rare openoffice-scale build I usually
need to resize the tmpfs or run off of disk.
If you're swapping you might wonder what the advantage of using tmpfs over
a regular filesystem is. After all, it is getting written to disk either
way, right? Well, if you write to a regular filesystem the system will
hold the data in buffers/cache for no more than a few seconds - to
minimize the amount of data lost if power fails. After all, if you write
to a filesystem you expect the data to be around after a reboot. On the
other hand, with tmpfs the memory gets swapped like anything else based on
frequency of use and all that. There is no long-term concern for
fragmented disk space, and a frequently accessed file will never get
swapped at all. At the end of the emerge, the work directory is deleted
and rather than a mad rush to update inodes the memory is simply
unallocated (which requires no disk access).
Some day I should time a build using tmpfs vs a regular filesystem and see
how large the difference is. Obviously it will be more pronounced for
those with more RAM - although even Duncan might have to resort to turning
on swap to actually take advantage of it.
firstname.lastname@example.org mailing list