1 |
On Tue, July 12, 2005 1:51 pm, Kyle Liddell said: |
2 |
> but will help when you realize "oh no, I need another 500mb |
3 |
> for /var/tmp/portage"... |
4 |
> |
5 |
|
6 |
On my system I have /tmp and /var/tmp mounted as tmpfs. My philosophy is |
7 |
that nothing important should be in there anyway, and if I'm buliding I |
8 |
really don't care whether the files being compiled are ever committed to |
9 |
disk. The advantage of tmpfs is that if there is no need to free up RAM, |
10 |
your build directory will never get written to disk at all - just the |
11 |
final merged files. Of course, you'll need a few GB of RAM/swap to |
12 |
accomplish this, and when doing the rare openoffice-scale build I usually |
13 |
need to resize the tmpfs or run off of disk. |
14 |
|
15 |
If you're swapping you might wonder what the advantage of using tmpfs over |
16 |
a regular filesystem is. After all, it is getting written to disk either |
17 |
way, right? Well, if you write to a regular filesystem the system will |
18 |
hold the data in buffers/cache for no more than a few seconds - to |
19 |
minimize the amount of data lost if power fails. After all, if you write |
20 |
to a filesystem you expect the data to be around after a reboot. On the |
21 |
other hand, with tmpfs the memory gets swapped like anything else based on |
22 |
frequency of use and all that. There is no long-term concern for |
23 |
fragmented disk space, and a frequently accessed file will never get |
24 |
swapped at all. At the end of the emerge, the work directory is deleted |
25 |
and rather than a mad rush to update inodes the memory is simply |
26 |
unallocated (which requires no disk access). |
27 |
|
28 |
Some day I should time a build using tmpfs vs a regular filesystem and see |
29 |
how large the difference is. Obviously it will be more pronounced for |
30 |
those with more RAM - although even Duncan might have to resort to turning |
31 |
on swap to actually take advantage of it. |
32 |
-- |
33 |
gentoo-amd64@g.o mailing list |