[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-user
Subject:    Re: partition reporting full, but not
From:       David Wright <deblis () lionunicorn ! co ! uk>
Date:       2024-02-21 18:30:41
Message-ID: ZdZBUQWi66eFpM+v () axis ! corp
[Download RAW message or body]

On Mon 19 Feb 2024 at 10:26:05 (+1100), Keith Bainbridge wrote:
> On 18/2/24 14:49, Keith Bainbridge wrote:
> > On 18/2/24 07:34, debian-user@howorth.org.uk wrote:
> > > Keith Bainbridge wrote:
> > > > Yes the / partitions are btrfs
> > > 
> > > So the apparently missing space is perhaps taken up by btrfs snapshots.
> > > 
> > 
> > Seems to be the prime suspect.   If that's the case, btrfs is NOT
> > hard- linking the snapshots as timeshift claims it does. The only
> > way to check is install on ext4 and compare. I have saves enough
> > free space to do this.
> > 
> > My effort to date is to move my home to /mnt/data and sim-link it
> > into / home. df is now showing 2.3GB free on /.  df showed /home
> > as 2.2GB yesterday.  At least there is a little space to play
> > with; and give me time to consider. A fresh install may be worth
> > checking in snapshots are as big as this all makes them look.
> > 
> > a few brief answer to other comments will follow
> 
> 
> So later yesterday afternoon I created a new snapshot with no obvious
> change is free space.

That would seem reasonable, as there's not much more to do than note
which files the snapshot contains.

> I then update/upgrade.   The initial attempt told me
> 63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
> Need to get 337 MB of archives.
> After this operation, 473 MB of additional disk space will be used.
> Do you want to continue? [Y/n]
> 
> But the 3 kernel related packages failed to install a couple of times.
> When I finally figured I should check space, there was none.   I
> rolled back to prior to the upgrade, but still no free space.
> 
> I said sometime in this thread that timeshift (and BiT) use hard links
> to create progressive copies of the system. The more I think about how
> hard links reportedly work, I reckon it can't be simply hard links.

Reading a tiny bit of the BTRFS docs, I would suggest that you're not
taking Block Groups into account. If BTRFS allocates data chunks in
blocks of 1GB, then it's conceivable that an upgrade involving 473MB
of data, plus the consequential increase in the size of the snapshot,
could all reside in a very recently created Block Group.

Put another way, df would see no change in Used and Available (as no
new Block Group allocation), whereas I would expect   btrfs filesystem df
to report a change here (because it knows what's within its Block
Groups):

> Data, single: total=32.80GiB, used=31.94GiB
> Tue 20Feb2024@20:57:45

Cheers,
David.

[prev in list] [next in list] [prev in thread] [next in thread]