[gentoo-dev] Re: News item review: SquashDelta syncing support

[Martin Vaeth <martin@mvath.de>]

Brian Dolbec <dolsen@gentoo.org> wrote:
> Martin Vaeth <martin@mvath.de> wrote:
>>
>> However, currently this does not play nicely with squashdelta:
>> You have to "undo" the mounting of squashdelta and have to use
>> different command (e.g. squashmount) afterwards.
>
> No, that is not correct [...]
> 2) /etc/portage/repo.postsync.d

I know about this hook, but this is not what I meant.

What I meant is the possibility to *replace* the automatic
mounting of portage by a different command (for instance,
a possibility to *avoid* that portage mounts/umounts
automatically but expects this to happens in this hook).

I give reasons for this below.

(This discussion belongs actually to portage-devel mailing
list or to some bug, but now I feel the necessity to clarify
the misunderstanding.)

It is not only inefficient and hackish (with possible problems
in case of unexpected situations like a SIGINT or other signal
at a "bad" time) if two programs/scripts "fight" about mounts
and undo each others' mounts. It also causes severe difficulties
in connection with overlayfs/aufs/...:

With these filesystems, you must create two (in case of
overlayfs even three) auxiliary directories, and in this
situation, it might be natural to choose these as
temporary direcories (e.g. generated in /tmp with unique names);
to understand the following explanation note also that two
of these directories (the squash filesystem and the overlay
filesystem) should "normally" always be mounted/umounted
together.

Now if portage umounts only the "overlay" directory,
the information about the temporary directory names is lost
(leaving possibly quite a bit data in /tmp undeleted
forever), and the second necessary "umount" does not
happen and is hard to do later on: It prevents the
space of the old squash file from actually being freed
(and this mount is hard to find later on: It is a mount
of a deleted file on an unknown temporary directory.
Of course, one could try to find this mount by some heuristic,
but this is extremely hackish, and the heuristic might find
some other squash file which the user has mounted similarly
for some other reason.)

In case of the mentioned "squashmount" tool, the situation
is better, because "squashmount" is rather complex and e.g.
stores/manages the names of temporary directories independently.
However, users might also want to use less sophisticated tools
than "squashmount" (and also "squashmount" has no easy solution
for "random" remounts of the mount points it manages, because
it is almost impossible to write a "generic" such solution.)

In any case, it is rather hackisch to write a lot of additional
code to "undo" an actually undesired umounting+mounting:
The "clean" solution appears to be to not do the "undesired"
(in this situation) umounting+mounting in the first place but
to execute *only* the actually desired (u)mount command(s)
instead.