linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Noah Massey <noah.massey@gmail.com>
To: menion@gmail.com
Cc: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
	Chris Murphy <lists@colorremedies.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs)
Date: Tue, 28 Aug 2018 14:06:53 -0400	[thread overview]
Message-ID: <CADfjVrhAcPE4L2o=m8LmbLQJ6LbRtRsJVZ6WWhRfcUC=AOL4tA@mail.gmail.com> (raw)
In-Reply-To: <CAJVZm6dcsuUZEnFncOmu6C7AVOpi6K4k=8rrOO=82yEqkY5UGA@mail.gmail.com>

On Tue, Aug 28, 2018 at 1:25 PM Menion <menion@gmail.com> wrote:
>
> Ok, I have removed the snapshot and the free expected space is here, thank you!
> As a side note: apt-btrfs-snapshot was not installed, but it is
> present in Ubuntu repository and I have used it (and I like the idea
> of automatic snapshot during upgrade)
> This means that the do-release-upgrade does it's own job on BTRFS,
> silently which I believe is not good from the usability perspective,

You are correct. DistUpgradeController.py from python3-distupgrade
imports 'apt_btrfs_snapshot', which I read as coming from
/usr/lib/python3/dist-packages/apt_btrfs_snapshot.py, supplied by
apt-btrfs-snapshot, but I missed the fact that python3-distupgrade
ships its own /usr/lib/python3/dist-packages/DistUpgrade/apt_btrfs_snapshot.py

So now it looks like that cannot be easily disabled, and without the
apt-btrfs-snapshot package scheduling cleanups it's not ever
automatically removed?

> just google it, there is no mention of this behaviour
> Il giorno mar 28 ago 2018 alle ore 19:07 Austin S. Hemmelgarn
> <ahferroin7@gmail.com> ha scritto:
> >
> > On 2018-08-28 12:05, Noah Massey wrote:
> > > On Tue, Aug 28, 2018 at 11:47 AM Austin S. Hemmelgarn
> > > <ahferroin7@gmail.com> wrote:
> > >>
> > >> On 2018-08-28 11:27, Noah Massey wrote:
> > >>> On Tue, Aug 28, 2018 at 10:59 AM Menion <menion@gmail.com> wrote:
> > >>>>
> > >>>> [sudo] password for menion:
> > >>>> ID      gen     top level       path
> > >>>> --      ---     ---------       ----
> > >>>> 257     600627  5               <FS_TREE>/@
> > >>>> 258     600626  5               <FS_TREE>/@home
> > >>>> 296     599489  5
> > >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55
> > >>>> 297     599489  5
> > >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:30:08
> > >>>> 298     599489  5
> > >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:33:30
> > >>>>
> > >>>> So, there are snapshots, right? The time stamp is when I have launched
> > >>>> do-release-upgrade, but it didn't ask anything about snapshot, neither
> > >>>> I asked for it.
> > >>>
> > >>> This is an Ubuntu thing
> > >>> `apt show apt-btrfs-snapshot`
> > >>> which "will create a btrfs snapshot of the root filesystem each time
> > >>> that apt installs/removes/upgrades a software package."
> > >> Not Ubuntu, Debian.  It's just that Ubuntu installs and configures the
> > >> package by default, while Debian does not.
> > >
> > > Ubuntu also maintains the package, and I did not find it in Debian repositories.
> > > I think it's also worth mentioning that these snapshots were created
> > > by the do-release-upgrade script using the package directly, not as a
> > > result of the apt configuration. Meaning if you do not want a snapshot
> > > taken prior to upgrade, you have to remove the apt-btrfs-snapshot
> > > package prior to running the upgrade script. You cannot just update
> > > /etc/apt/apt.conf.d/80-btrfs-snapshot
> > Hmm... I could have sworn that it was in the Debian repositories.
> >
> > That said, it's kind of stupid that the snapshot is not trivially
> > optional for a release upgrade.  Yes, that's where it's arguably the
> > most important, but it's still kind of stupid to have to remove a
> > package to get rid of that behavior and then reinstall it again afterwards.

  reply	other threads:[~2018-08-28 22:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28  9:34 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) Menion
2018-08-28 11:54 ` Qu Wenruo
2018-08-28 13:07   ` Menion
2018-08-28 13:22     ` Qu Wenruo
2018-08-28 13:47 ` Chris Murphy
2018-08-28 14:56   ` Menion
2018-08-28 15:27     ` Noah Massey
2018-08-28 15:47       ` Austin S. Hemmelgarn
2018-08-28 16:05         ` Noah Massey
2018-08-28 17:07           ` Austin S. Hemmelgarn
2018-08-28 17:25             ` Menion
2018-08-28 18:06               ` Noah Massey [this message]
     [not found]                 ` <CAJVZm6dpfQghX+cCo=LkqZMAtFfCMKtq+XHpNGb6wH8z8eMcQA@mail.gmail.com>
2018-08-28 19:47                   ` Austin S. Hemmelgarn
2018-08-29  0:16                   ` Chris Murphy
2018-08-29  0:10     ` 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='CADfjVrhAcPE4L2o=m8LmbLQJ6LbRtRsJVZ6WWhRfcUC=AOL4tA@mail.gmail.com' \
    --to=noah.massey@gmail.com \
    --cc=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=menion@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).