From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 22 13:05:26 2020 Received: (at 45266) by debbugs.gnu.org; 22 Dec 2020 18:05:26 +0000 Received: from localhost ([127.0.0.1]:50862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1krm2I-0005tE-1s for submit@debbugs.gnu.org; Tue, 22 Dec 2020 13:05:26 -0500 Received: from mail-lf1-f44.google.com ([209.85.167.44]:40123) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1krm2E-0005sx-Pc for 45266@debbugs.gnu.org; Tue, 22 Dec 2020 13:05:24 -0500 Received: by mail-lf1-f44.google.com with SMTP id m12so34042735lfo.7 for <45266@debbugs.gnu.org>; Tue, 22 Dec 2020 10:05:22 -0800 (PST) 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:content-transfer-encoding; bh=fxONOQeIRKG4vakyVStzYFRPbozBwSDYoqDjwpIkcqo=; b=dkIz2J9pWkJkmFahJhsHTm77uHLzrPo17T9hB+NlCo8d9w94Bux5ermU1oq7/Hgnlx tf0LfWQIJdrPzeNo/DTpyMOhZx9YX1iiWm8mNcfJHPKtIqQ1B9aKF+NCk6jLcki4jnGt JPVSrZamjhrbHWktXXCI/GkT20cr45WV4J6diHqtAhodz/zIEM9fRGgAsS+h/2Zq2rhO ZmnK5nbuWCegqX8tE0bca9syHaJ4LOzZXYd1oXEe04/QYIkMOCBUKTtMtcPMluAOiYZ4 MXQMuJj71+Kph7QD/E5uup774W7yx8PCgiPfQkTE7KMs6Hdn8T8PZ1Rq5aDlHN/2ga1O 0udQ== 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:content-transfer-encoding; bh=fxONOQeIRKG4vakyVStzYFRPbozBwSDYoqDjwpIkcqo=; b=Rq9bY4RqnNKlRMRn0yfN2g8+23MAeS1/OBmzcujS/ze7GGYBrjGJ2jEkdTsVQprm+y EmAkkStQsuRVFRPX9h2bVECLXOtICzLZIuLQP89kgjzA0bFsUB5sBrym/OjbS+dzSBTN NBRvOw6UbUIEm+U90yKemp4TbVCqmpZm8Aj02iZV4WrMRWG9ApvBJf14Vq2BUxwpOpll G1fkx+STHPQo31/l2kudMRoL9UBiUzaHwDdEvJJ4cNojPcoxfVYL+2An7fTq0p8N8Vdz fleWvF9nz/VsbflkrMNm+L0OsMWjtpCUFJcSXJDDEEUh306QdCmhIC4zz3h/aGF/n/La sraw== X-Gm-Message-State: AOAM530B/rmIVpPm0FQUpdr4bC+IAycIzAO4G1MwgBq0zeSuYYjl4Hlf rqJ1Yg9uA+Gv+kVCOndGnPoUsWDTu03KbC1FlRhHVsP3QXE= X-Google-Smtp-Source: ABdhPJwewrOkX5pXFGLbQIEDK9aR31LhvjERed48EFhonaXXnI31OGybCnPYAKoSAzK5S+xZ0oBVr2Mz3a9u7QfvXmw= X-Received: by 2002:a05:6512:304c:: with SMTP id b12mr8817830lfb.273.1608660315948; Tue, 22 Dec 2020 10:05:15 -0800 (PST) MIME-Version: 1.0 References: <875z4t29g6.fsf@gnu.org> In-Reply-To: <875z4t29g6.fsf@gnu.org> From: Nathan Dehnel Date: Tue, 22 Dec 2020 12:05:04 -0600 Message-ID: Subject: Re: bug#45266: "guix gc" needs free disk space to function To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45266 Cc: 45266@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >The daemon reserves a bit of extra space before starting operation (see =E2=80=98reserve-space?=E2=80=99 in (guix store)), which should be enough t= o gracefully handle situations where builds are filling the disk. >However, there can also be non-Guix processes filling the disk, to the point where it=E2=80=99s completely full, and at that point sqlite3 (which = the daemon uses) may be unable to operate. I didn't experience this. Guix pull filled the disk, which prevented the gc from working. It's possible some other process was writing in the background, but I had built an image which was almost completely devoid of programs and services. >I=E2=80=99m afraid there=E2=80=99s little we can do in this case. >Thoughts? Copy the database into tmpfs temporarily? On Tue, Dec 22, 2020 at 8:37 AM Ludovic Court=C3=A8s wrote: > > Hi, > > Nathan Dehnel skribis: > > > It would be better if guix gc could run on a disk that was completely > > full, as right now it cannot be used to free space on a full disk. > > The daemon reserves a bit of extra space before starting operation (see > =E2=80=98reserve-space?=E2=80=99 in (guix store)), which should be enough= to gracefully > handle situations where builds are filling the disk. > > However, there can also be non-Guix processes filling the disk, to the > point where it=E2=80=99s completely full, and at that point sqlite3 (whic= h the > daemon uses) may be unable to operate. > > I=E2=80=99m afraid there=E2=80=99s little we can do in this case. > > Thoughts? > > Ludo=E2=80=99.