1 |
Tim Harder <radhermit@g.o> wrote: |
2 |
> On 2017-09-23 19:59, Rich Freeman wrote: |
3 |
>> A read-only container |
4 |
> |
5 |
> I doubt bind mounts will scale |
6 |
> |
7 |
> As has been mentioned before, a different way would be to write some |
8 |
> sort of FUSE fs |
9 |
|
10 |
The problem with both, containers and FUSE, is performance. |
11 |
(For containers with thousands of binds, I haven't tried, |
12 |
but for FUSE I know how unionfs-fuse slows down "normal" |
13 |
operation: only for the reason that the implementation in |
14 |
userspace requires many additional context switches.) |
15 |
|
16 |
Both is fine for testing, but I am afraid not for regular |
17 |
user's emerge operations which usually involve too many file |
18 |
operations, at least for certain packages (e.g. *-sources, |
19 |
texlive-*). |
20 |
|
21 |
It is the big advantage of overlay that it is implemented in |
22 |
kernel and does not involve any time-consuming checks during |
23 |
normal file operations. |
24 |
|
25 |
Indeed, the price you pay is that the actual checking can be |
26 |
done only once only at the very end of the compilation, and |
27 |
so the only information you get is the name and time of |
28 |
violation (paths and filestamps). But concerning performance |
29 |
this "only once" checking is an advantage, of course. |
30 |
|
31 |
Main disadvantages: It requires the user to have overlay |
32 |
support in the kernel and extended attribute support for |
33 |
the file system containing the upper directory. |