1 |
Brian Dolbec <dolsen@g.o> wrote: |
2 |
> Martin Vaeth <martin@×××××.de> wrote: |
3 |
>> |
4 |
>> However, currently this does not play nicely with squashdelta: |
5 |
>> You have to "undo" the mounting of squashdelta and have to use |
6 |
>> different command (e.g. squashmount) afterwards. |
7 |
> |
8 |
> No, that is not correct [...] |
9 |
> 2) /etc/portage/repo.postsync.d |
10 |
|
11 |
I know about this hook, but this is not what I meant. |
12 |
|
13 |
What I meant is the possibility to *replace* the automatic |
14 |
mounting of portage by a different command (for instance, |
15 |
a possibility to *avoid* that portage mounts/umounts |
16 |
automatically but expects this to happens in this hook). |
17 |
|
18 |
I give reasons for this below. |
19 |
|
20 |
(This discussion belongs actually to portage-devel mailing |
21 |
list or to some bug, but now I feel the necessity to clarify |
22 |
the misunderstanding.) |
23 |
|
24 |
It is not only inefficient and hackish (with possible problems |
25 |
in case of unexpected situations like a SIGINT or other signal |
26 |
at a "bad" time) if two programs/scripts "fight" about mounts |
27 |
and undo each others' mounts. It also causes severe difficulties |
28 |
in connection with overlayfs/aufs/...: |
29 |
|
30 |
With these filesystems, you must create two (in case of |
31 |
overlayfs even three) auxiliary directories, and in this |
32 |
situation, it might be natural to choose these as |
33 |
temporary direcories (e.g. generated in /tmp with unique names); |
34 |
to understand the following explanation note also that two |
35 |
of these directories (the squash filesystem and the overlay |
36 |
filesystem) should "normally" always be mounted/umounted |
37 |
together. |
38 |
|
39 |
Now if portage umounts only the "overlay" directory, |
40 |
the information about the temporary directory names is lost |
41 |
(leaving possibly quite a bit data in /tmp undeleted |
42 |
forever), and the second necessary "umount" does not |
43 |
happen and is hard to do later on: It prevents the |
44 |
space of the old squash file from actually being freed |
45 |
(and this mount is hard to find later on: It is a mount |
46 |
of a deleted file on an unknown temporary directory. |
47 |
Of course, one could try to find this mount by some heuristic, |
48 |
but this is extremely hackish, and the heuristic might find |
49 |
some other squash file which the user has mounted similarly |
50 |
for some other reason.) |
51 |
|
52 |
In case of the mentioned "squashmount" tool, the situation |
53 |
is better, because "squashmount" is rather complex and e.g. |
54 |
stores/manages the names of temporary directories independently. |
55 |
However, users might also want to use less sophisticated tools |
56 |
than "squashmount" (and also "squashmount" has no easy solution |
57 |
for "random" remounts of the mount points it manages, because |
58 |
it is almost impossible to write a "generic" such solution.) |
59 |
|
60 |
In any case, it is rather hackisch to write a lot of additional |
61 |
code to "undo" an actually undesired umounting+mounting: |
62 |
The "clean" solution appears to be to not do the "undesired" |
63 |
(in this situation) umounting+mounting in the first place but |
64 |
to execute *only* the actually desired (u)mount command(s) |
65 |
instead. |