All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Boris Burkov <boris@bur.io>
Cc: "Apostolos B." <barz621@gmail.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
	systemd Mailing List <systemd-devel@lists.freedesktop.org>
Subject: Re: No space left errors on shutdown with systemd-homed /home dir
Date: Thu, 27 Jan 2022 13:48:24 -0700	[thread overview]
Message-ID: <CAJCQCtR5ngU8oF6apChzBgFgX1W-9CVcF9kjvgStbkcAq_TsHQ@mail.gmail.com> (raw)
In-Reply-To: <YfHXFfHMeqx4MowJ@zen>

On Wed, Jan 26, 2022 at 4:19 PM Boris Burkov <boris@bur.io> wrote:
>
> On Thu, Jan 27, 2022 at 12:07:53AM +0200, Apostolos B. wrote:
> >  This is what homectl inspect user reports:
> >
> >   Disk Size: 128.0G
> >   Disk Usage: 3.8G (= 3.1%)
> >   Disk Free: 124.0G (= 96.9%)
> >
> > and this is what btrfs usage reports:
> >
> > sudo btrfs filesystem usage /home/toliz
> >
> > Overall:
> >     Device size:             127.98GiB
> >     Device allocated:               4.02GiB
> >     Device unallocated:     123.96GiB
> >     Device missing:                 0.00B
> >     Used:                           1.89GiB
> >     Free (estimated):             124.10GiB    (min: 62.12GiB)
> >     Free (statfs, df):             124.10GiB
> >     Data ratio:                  1.00
> >     Metadata ratio:                  2.00
> >     Global reserve:               5.14MiB    (used: 0.00B)
> >     Multiple profiles:                    no
> >
> > Data,single: Size:2.01GiB, Used:1.86GiB (92.73%)
> >    /dev/mapper/home-toliz       2.01GiB
> >
> > Metadata,DUP: Size:1.00GiB, Used:12.47MiB (1.22%)
> >    /dev/mapper/home-toliz       2.00GiB
> >
> > System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)
> >    /dev/mapper/home-toliz      16.00MiB
> >
> > Unallocated:
> >    /dev/mapper/home-toliz     123.96GiB
> >
>
> OK, there is plenty of unallocated space, thanks for confirming.
>
> Looking at the stack trace a bit more, the only thing that really sticks
> out as suspicious to me is btrfs_shrink_device, I'm not sure who would
> want to do that or why.

systemd-homed by default uses btrfs on LUKS on loop mount, with a
backing file. On login, it grows the user home file system with some
percentage (I think 80%) of the free space of the underlying file
system. And on logout, it does both fstrim and shrinks the fs. I don't
know why it does both, it seems adequate to do only fstrim on logout
to return unused blocks to the underlying file system; and to do an fs
resize on login to either grow or shrink the user home file system.

But also, we don't really have a great estimator of the minimum size a
file system can be. `btrfs inspect-internal min-dev-size` is pretty
broken right now.
https://github.com/kdave/btrfs-progs/issues/271

I'm not sure if systemd folks would use libbtrfsutil facility to
determine the minimum device shrink size? But also even the kernel
doesn't have a very good idea of how small a file system can be
shrunk. Right now it basically has to just start trying, and does it
one block group at a time.

Adding systemd-devel@


-- 
Chris Murphy

  parent reply	other threads:[~2022-01-27 20:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 17:46 No space left errors on shutdown with systemd-homed /home dir Apostolos B.
2022-01-26 21:50 ` Boris Burkov
2022-01-26 22:07   ` Apostolos B.
2022-01-26 23:19     ` Boris Burkov
2022-01-26 23:29       ` Apostolos B.
2022-01-27  7:59         ` Wang Yugui
2022-01-27  8:51           ` Wang Yugui
2022-01-27 19:13         ` Goffredo Baroncelli
2022-01-27 20:48       ` Chris Murphy [this message]
2022-01-29  9:53         ` Goffredo Baroncelli
2022-01-29 18:01           ` Chris Murphy
2022-01-30  9:27             ` Goffredo Baroncelli
2022-01-31  9:41               ` Colin Guthrie
2022-02-01 19:55                 ` Neal Gompa
2022-05-31 12:44                   ` Colin Guthrie
2022-05-31 18:12                     ` Goffredo Baroncelli
2022-06-01  9:36                       ` Colin Guthrie
2022-07-23 19:09                         ` Chris Murphy
2022-02-01  4:26           ` Zygo Blaxell
2022-07-23 19:26             ` Chris Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJCQCtR5ngU8oF6apChzBgFgX1W-9CVcF9kjvgStbkcAq_TsHQ@mail.gmail.com \
    --to=lists@colorremedies.com \
    --cc=barz621@gmail.com \
    --cc=boris@bur.io \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=systemd-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.