All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neal Gompa <ngompa13@gmail.com>
To: Colin Guthrie <colin@booksterhq.com>
Cc: kreijack@inwind.it, Chris Murphy <lists@colorremedies.com>,
	Boris Burkov <boris@bur.io>, "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: Tue, 1 Feb 2022 14:55:51 -0500	[thread overview]
Message-ID: <CAEg-Je9rr4Y7JQbD3iO1UqMy48j7feAXFFeaqpJc6eP7FSduEw@mail.gmail.com> (raw)
In-Reply-To: <367f0891-f286-198b-617c-279dc61a2c3b@colin.guthr.ie>

On Tue, Feb 1, 2022 at 2:02 PM Colin Guthrie <colin@booksterhq.com> wrote:
>
> Goffredo Baroncelli wrote on 30/01/2022 09:27:
> > On 29/01/2022 19.01, Chris Murphy wrote:
> >> On Sat, Jan 29, 2022 at 2:53 AM Goffredo Baroncelli
> >> <kreijack@libero.it> wrote:
> >>>
> >>> I think that for the systemd uses cases (singled device FS), a simpler
> >>> approach would be:
> >>>
> >>>       fstatfs(fd, &sfs)
> >>>       needed = sfs.f_blocks - sfs.f_bavail;
> >>>       needed *= sfs.f_bsize
> >>>
> >>>       needed = roundup_64(needed, 3*(1024*1024*1024))
> >>>
> >>> Comparing the original systemd-homed code, I made the following changes
> >>> - 1) f_bfree is replaced by f_bavail (which seem to be more
> >>> consistent to the disk usage; to me it seems to consider also the
> >>> metadata chunk allocation)
> >>> - 2) the needing value is rounded up of 3GB in order to consider a
> >>> further 1 data chunk and 2 metadata chunk (DUP))
> >>>
> >>> Comments ?
> >>
> >> I'm still wondering if such a significant shrink is even indicated, in
> >> lieu of trim. Isn't it sufficient to just trim on logout, thus
> >> returning unused blocks to the underlying filesystem?
> >
> > I agree with you. In Fedora 35, and the default is ext4+luks+trim
> > which provides the same results. However I remember that in the past the
> > default
> > was btrfs+luks+shrunk. I think that something is changed i.
> >
> > However, I want to provide do the systemd folks a suggestion ho change
> > the code.
> > Even a warning like: "it doesn't work that because this, please drop it"
> > would be sufficient.
>
>
> Out of curiosity (see other thread on the systemd list about this), what
> it the current recommendation (by systemd/btrfs folks rather then Fedora
> defaults) for homed machine partitioning?
>

I'd probably recommend Btrfs with the /home subvolume set with
nodatacow if you're going to use loops of LUKS backed Btrfs homedir
images. The individual Btrfs loops will have their own COW anyway.

Otherwise, the Fedora defaults for Btrfs should be sufficient.



--
真実はいつも一つ!/ Always, there's only one truth!

  reply	other threads:[~2022-02-01 19:56 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
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 [this message]
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=CAEg-Je9rr4Y7JQbD3iO1UqMy48j7feAXFFeaqpJc6eP7FSduEw@mail.gmail.com \
    --to=ngompa13@gmail.com \
    --cc=barz621@gmail.com \
    --cc=boris@bur.io \
    --cc=colin@booksterhq.com \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --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.