1 |
Am 10.03.2012 14:30, schrieb Alex Schuster: |
2 |
> Hi there! |
3 |
> |
4 |
> Is there an advantage in putting the portage tree on an extra partition? |
5 |
> |
6 |
|
7 |
Yes. It allows you to use a smaller and more appropriate block size like |
8 |
1k or 2k which decreases internal fragmentation. It also increases |
9 |
locality of data, meaning that you won't scatter your files all over |
10 |
your 2TB hard disk. Ext* and co. have mechanisms to prevent this but it |
11 |
still helps to enforce it. |
12 |
|
13 |
> Currently, I'm using reiserfs, because I read that it is efficient when |
14 |
> using many small files. On the other hand I also heard that it tends to |
15 |
> get slower with every emerge --sync. |
16 |
> |
17 |
|
18 |
Yes, that's a problem of every file system. Reiserfs (especially without |
19 |
notail) and btrfs are more prone to this due to their internal organization. |
20 |
|
21 |
> Space is no longer an argument in these days, at least for my desktop |
22 |
> machine. But I would like to optimize for speed -- emerge -DputnVj |
23 |
> @world takes quite a while to calculate, I assume this is because so many |
24 |
> ebuild files have to be accessed. |
25 |
> |
26 |
|
27 |
Not just ebuilds. You also have to consider /var/cache/edb and |
28 |
/var/db/pkg. Be careful with the latter one. You don't want to loose its |
29 |
content. |
30 |
|
31 |
> Any tips on this? Does it make sense to use a special file system just |
32 |
> for the portage tree? What would be best? Would it help to re-create this |
33 |
> file system from time to time in case it gets slower with every sync? Or |
34 |
> wouldn't I notice a difference if I just used a big ext4 partition for |
35 |
> all portage related stuff? |
36 |
> |
37 |
> Anyone using a compressed RAM file system for that? :) |
38 |
> |
39 |
> Wonko |
40 |
> |
41 |
|
42 |
Recreating it certainly helps. I don't find it worth the effort. though. |
43 |
|
44 |
Regards, |
45 |
Florian Philipp |