Very cool - thanks Chris! In the meantime, I've updated my build script to externalize the Guix environment from the Docker container. So far the daily builds are staying nice and small at ~197MB and one layer. The images and updated script are here if anybody is curious:
https://hub.docker.com/r/singularsyntax/guix/tags https://gitlab.com/singularsyntax-docker-hub/guix/-/blob/master/.gitlab-ci.yml GitLab allows you to cache files between job stages and even full pipeline runs. I first tried to cache /var/guix and /gnu/store and mount them inside a container in which to perform `guix pull` etc. However, it seems that handling hard links on externally mounted file systems from within a container is problematic. I think passing `--disable-deduplication` to guix-daemon might resolve it, but I couldn't figure out where/how to change the Shepherd configuration to do that. So instead, I just copy the directories into and out of the container at start and end of the process. It seems to work. Mounting would probably speed up the process quite a bit if I could make it work. Cheers, -Steve On Fri, Jun 5, 2020 at 5:32 AM Christopher Marusich <cmmarus...@gmail.com> wrote: > Chris Marusich <cmmarus...@gmail.com> writes: > > > Ludovic Courtès <l...@gnu.org> writes: > > > >>> Should Guix do anything about this? We could change guix-daemon to > take > >>> correct action in the face of an XDEV error. We could also improve the > >>> logging, since currently it silently swallows the XDEV error. > >> > >> I guess we could delete recursively right away upon EXDEV. It should be > >> just two lines of code, right? > > > > I'll try making the change and report back. Yes, there are other cases > > where we immediately delete without moving into the trash directory > > (e.g., when the trash directory fails to be created), so it seems OK. > > Here is a patch. Turns out it's was just a one line change! If nobody > has any further feedback on it, I'll go ahead and merge it to the master > branch in the next couple days. > > I tested it in one of the Docker containers provided by Stephen which > exhibited the problem. I built the new Guix inside the Docker container > and verified that a path which was previously unable to be GC'd due to > the EXDEV error, was now able to be successfully GC'd. > > My understanding is that the only reason why the guix-daemon attempts to > move dead directories to the trash directory is to save time on > deleting, since large directories could take a while to fully delete. > If there is any reason why it might be unsafe to delete the directories > directly in case of EXDEV (I cannot think of any), please let me know. > > -- > Chris >
