From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id sFIYF3Tu016iVAAA0tVLHw (envelope-from ) for ; Sun, 31 May 2020 17:50:44 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id OBDrEnTu015DHQAAB5/wlQ (envelope-from ) for ; Sun, 31 May 2020 17:50:44 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 186FF9404C5 for ; Sun, 31 May 2020 17:50:44 +0000 (UTC) Received: from localhost ([::1]:38014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jfS6d-0001xy-16 for larch@yhetil.org; Sun, 31 May 2020 13:50:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jfS6I-0001wo-6K for help-guix@gnu.org; Sun, 31 May 2020 13:50:22 -0400 Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]:35232) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jfS6H-0006fv-17 for help-guix@gnu.org; Sun, 31 May 2020 13:50:21 -0400 Received: by mail-lj1-x234.google.com with SMTP id c11so5335681ljn.2 for ; Sun, 31 May 2020 10:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K5Yb8SMU8yFaP5LU8fyNB+D9/4Pctssf6+50Ng5iGO0=; b=hwFk1IX2tY+Ga+Dop9mWDNokGFEplg0bYzWibBK8LBlxx9A7YV2vNMmkhqwZsZUnmA vbAUQwDP8o4uXbCcsPhIrDrze7F+mKPRAbi1RDTGn0ZevUo2rpm8GjFx5ttKSqBOFzyC AWAhcpfjOtP9pGnIEtzqM6fYnmiPu9pZ17MZOuRWNztjET0XRb80e0aovDjOINYFO2Cn eQJs1LobUbOHJ+nm+NodA+Kq2zWrLcsIyRBojlWYGReTvoM5nWdmYZji+xig7Eh8hlFB 09OkejTME394ewEx6RCGhBmK3fWrr2rOv8Uzos5istxTInyup8W1on8ER6N2yMT4H3fD IZ3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K5Yb8SMU8yFaP5LU8fyNB+D9/4Pctssf6+50Ng5iGO0=; b=mnOOld9DV+T4OjY7r9VA1iJ9Yu8YFgv+hEro2BkvNzcNBoLe8WdBmamUwN19sOQ3Ay upOHlKG96n8ThttV8lnOzkcJPWGYvZpCacUefjvmITl/FUb33uC/2qRrB4/XrdHapf6X Rkz+ZbJJIdkB9q43SW4YIzaq963hGbaRA+jbTM1Jc+fktsPmZvFOHFvGxjAPJ57rBNjw xxmTWxkzJ5+Ppo2bON1W94pGfe19/hcZuhMAUSU2m64ohnI37T9VgRi7tIW24cpoMxfD OZLDJL9Z1vAz9U6Gv3Gc7Kw1Exqzb5jJNBOJQcsj+YrpbtDMwX+EA+eR0L6O2iBWzwHg RdHA== X-Gm-Message-State: AOAM532dtYnqcVnQZ81TuoL62/yv08OF/lp/ZYocEHonmt8FFxbVCPSb pwzSbqYa8wIEFrF6+/AjG4YOOzhdRmoq0xR5XQQ= X-Google-Smtp-Source: ABdhPJyUpKxBz90vPf+O8Zs/yO8nakIHDwmqmQlDTQ38jZNAV2UzTYy5OszjpSHeivKXIUVSx6zrcMv3jRPbkF9d51E= X-Received: by 2002:a05:651c:491:: with SMTP id s17mr8231030ljc.461.1590947418744; Sun, 31 May 2020 10:50:18 -0700 (PDT) MIME-Version: 1.0 References: <87h7vyxqrz.fsf@gmail.com> <87367glo7c.fsf@gmail.com> In-Reply-To: <87367glo7c.fsf@gmail.com> From: Stephen Scheck Date: Sun, 31 May 2020 13:50:06 -0400 Message-ID: Subject: Re: Guix Docker image inflation To: Chris Marusich Received-SPF: pass client-ip=2a00:1450:4864:20::234; envelope-from=singularsyntax@gmail.com; helo=mail-lj1-x234.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: help-guix Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: "Help-Guix" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (body hash did not verify) header.d=gmail.com header.s=20161025 header.b=hwFk1IX2; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-Spam-Score: 1.59 X-TUID: oSzfJ6yiK+p8 On Sun, May 31, 2020 at 12:31 AM Chris Marusich wrote: > > Also, layers are helpful in the case of someone pulling down daily > > Guix Docker images on a frequent basis, because then only the new, > > ideally small layers need to be downloaded, whereas if you rebase for > > every image build, you'd have to download the entire image every day. > > That is true, but suppose I have the following 3 images: > > - Image A: A base image created in January 2020. > - Image B: Based on A, and I ran "guix pull" in February 2020. > - Image C: Based on A, and I ran "guix pull" in June 2020. > > I would guess that the size difference between A and B is approximately > the same as the difference between A and C. It'll be different, of > course, but generally the size difference between A and C should not > grow linearly with time, since "guix pull" is only going to install at > most the total closure of things necessary to build and run Guix, which > doesn't increase much in size as time goes on. However, when you > daisy-chain the images every day, the image size will grow linearly with > time because the contents of all the previous layers is carried forward. > > > My build script issues several `docker exec ` > > sequences, followed by a `docker commit `. Intermediate > > changes to the container file system prior to the commit do not > > generate layers, only the net changes after the commit. > > There are two problems here. One is that the image size grows without > bound. The other is that guix-daemon is failing to GC store items in > the Docker container. Although they are both concerning, the latter is > not the cause of the former. > > If you install new store items (e.g., via "guix pull"), make them dead, > and then GC them, all in the same container before running "docker > commit", then I agree: those GC'd store items would not persist in a > layer anywhere. However, I don't think that's what's happening here. > Sure, there might be a few store items like this, but in practice, there > will be many store items from the previous image which began live but > became dead when you ran "guix pull" and deleted your old profile > generations. It is those store items that are adding the most space to > your image. > Yes, I get this. I never expected the container to stay constant in size, but I was hoping daily pulls would result in relatively low image growth. It's not clear to me if any of the items which should get GC'd but don't are just ephemeral build results, in which case growth might be tolerable with an occasional rebase (perhaps monthly or bi-monthly). But I'm now starting to doubt my whole approach because it seems like there are some fundamental GC problems with running a live Guix system inside a container. > Besides store items, I noticed two other things about your images: > > - The contents of /var is growing slowly without bound, but it isn't > nearly as bad as the contents of /gnu/store. This is probably due to > log files; consider pruning them. > These are presumably OK to delete, without any special handling for Guix? > - Your script runs "docker commit" while guix-daemon (and other > programs) are still running. To ensure the guix-daemon's database (or > other things) does not become corrupt, consider terminating all > processes before committing the new image. > `docker commit` pauses the container (unless you tell it not to) ... although I guess that could still cause problems if Guix store writes aren't implemented in an atomic way. Thanks, -SS