Groups > linux.debian.user > #267515 > unrolled thread

partition reporting full, but not

Started by	Keith Bainbridge <keithrbau@gmail.com>
First post	2024-02-17 03:40 +0100
Last post	2024-02-19 00:10 +0100
Articles	20 on this page of 47 — 13 participants

Back to article view | Back to linux.debian.user

  partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-17 03:40 +0100
    Re: partition reporting full, but not Gremlin <scott-andrews@columbus.rr.com> - 2024-02-17 04:00 +0100
      Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-17 05:50 +0100
        Re: partition reporting full, but not songbird <songbird@anthive.com> - 2024-02-17 13:40 +0100
    Re: partition reporting full, but not David Wright <deblis@lionunicorn.co.uk> - 2024-02-17 04:00 +0100
    Re: partition reporting full, but not Greg Wooledge <greg@wooledge.org> - 2024-02-17 04:00 +0100
      Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-17 05:50 +0100
        Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-17 07:10 +0100
          Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-17 10:20 +0100
            Re: partition reporting full, but not David Christensen <dpchrist@holgerdanske.com> - 2024-02-18 08:30 +0100
        Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-17 07:20 +0100
        Re: partition reporting full, but not debian-user@howorth.org.uk - 2024-02-17 21:40 +0100
          Re: partition reporting full, but not Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-17 22:10 +0100
            Re: partition reporting full, but not Greg Wooledge <greg@wooledge.org> - 2024-02-17 22:10 +0100
              Re: partition reporting full, but not Cindy Sue Causey <butterflybytes@gmail.com> - 2024-02-17 23:20 +0100
                Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-18 05:00 +0100
          Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-18 05:00 +0100
            Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-19 00:30 +0100
              Re: partition reporting full, but not Max Nikulin <manikulin@gmail.com> - 2024-02-19 03:10 +0100
                Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-20 07:50 +0100
                  Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-20 08:50 +0100
                    Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-20 09:40 +0100
                      Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-20 11:30 +0100
                        Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-20 11:40 +0100
                      Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-20 20:50 +0100
                        Re: partition reporting full, but not Greg Wooledge <greg@wooledge.org> - 2024-02-20 21:00 +0100
                          Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-21 00:50 +0100
                            Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-21 02:30 +0100
                              Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-21 06:50 +0100
                      Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-21 01:40 +0100
                        Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-21 02:00 +0100
                          Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-21 02:20 +0100
                    Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-20 11:20 +0100
                      Re: partition reporting full, but not "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-20 12:40 +0100
                    Re: partition reporting full, but not debian-user@howorth.org.uk - 2024-02-20 18:20 +0100
              Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-19 04:30 +0100
                Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-19 06:50 +0100
                Re: partition reporting full, but not David Christensen <dpchrist@holgerdanske.com> - 2024-02-19 08:40 +0100
                  Re: partition reporting full, but not debian-user@howorth.org.uk - 2024-02-19 12:30 +0100
                Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-20 08:20 +0100
                  Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-20 09:00 +0100
              Re: partition reporting full, but not David Wright <deblis@lionunicorn.co.uk> - 2024-02-21 19:40 +0100
            Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-19 03:50 +0100
            Re: partition reporting full, but not Felix Miata <mrmazda@earthlink.net> - 2024-02-19 03:50 +0100
      Re: partition reporting full, but not <tomas@tuxteam.de> - 2024-02-17 07:10 +0100
      Re: partition reporting full, but not Max Nikulin <manikulin@gmail.com> - 2024-02-18 04:10 +0100
        Re: partition reporting full, but not Keith Bainbridge <keithrbau@gmail.com> - 2024-02-19 00:10 +0100

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#267617

From	Felix Miata <mrmazda@earthlink.net>
Date	2024-02-20 08:50 +0100
Message-ID	<I9t33-bn85-1@gated-at.bofh.it>
In reply to	#267614

Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):

> I just removed 3 snapshots from my daily driver with no change in used 
> space reported by df

df doesn't know how to calculate freespace on btrfs. You need to be typing

	btrfs filesystem df

if you have not aliased df to btrfs filesystem df.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#267622

From	<tomas@tuxteam.de>
Date	2024-02-20 09:40 +0100
Message-ID	<I9tPr-bnDr-1@gated-at.bofh.it>
In reply to	#267617

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 20, 2024 at 02:42:18AM -0500, Felix Miata wrote:
> Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):
> 
> > I just removed 3 snapshots from my daily driver with no change in used 
> > space reported by df
> 
> df doesn't know how to calculate freespace on btrfs. You need to be typing
> 
> 	btrfs filesystem df
> 
> if you have not aliased df to btrfs filesystem df.

Still, Keith seems to have a real shortage of file system free space,
otherwise Debian upgrades wouldn't fail.

I don't know much about btrfs, but what would be really helpful (if
you do, and it seems so) would be for you to fill us in on how to
asses the space used up by old snapshots (what seems to be the main
suspect currently).

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#267628

From	Keith Bainbridge <keithrbau@gmail.com>
Date	2024-02-20 11:30 +0100
Message-ID	<I9vxT-boIJ-5@gated-at.bofh.it>
In reply to	#267622

On 20/2/24 19:38, tomas@tuxteam.de wrote:
> On Tue, Feb 20, 2024 at 02:42:18AM -0500, Felix Miata wrote:
>> Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):
>>
>>> I just removed 3 snapshots from my daily driver with no change in used
>>> space reported by df
>>
>> df doesn't know how to calculate freespace on btrfs. You need to be typing
>>
>> 	btrfs filesystem df
>>
>> if you have not aliased df to btrfs filesystem df.
> 
> Still, Keith seems to have a real shortage of file system free space,
> otherwise Debian upgrades wouldn't fail.
> 
> I don't know much about btrfs, but what would be really helpful (if
> you do, and it seems so) would be for you to fill us in on how to
> asses the space used up by old snapshots (what seems to be the main
> suspect currently).
> 
> Cheers

Tomas, the upgrade failure was earlier than these notes. It has now worked

Sorry, but I don't know how to assess the snapshot space usage.

-- 
All the best

Keith Bainbridge

keith.bainbridge.3216@gmail.com
+61 (0)447 667 468

UTC + 10:00

[toc] | [prev] | [next] | [standalone]

#267629

From	<tomas@tuxteam.de>
Date	2024-02-20 11:40 +0100
Message-ID	<I9vHz-boLT-7@gated-at.bofh.it>
In reply to	#267628

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 20, 2024 at 09:21:15PM +1100, Keith Bainbridge wrote:
> 
> On 20/2/24 19:38, tomas@tuxteam.de wrote:

[...]

> Tomas, the upgrade failure was earlier than these notes. It has now worked

I see.

> Sorry, but I don't know how to assess the snapshot space usage.

Nor do I -- my question was rather directed at Felix, who seems to
be the only one in this thread with some btrfs experience.

Perhaps it'd be wise to include "btrfs" in the Subject to attract
the attention of btrfs buffs?

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#267645

From	Felix Miata <mrmazda@earthlink.net>
Date	2024-02-20 20:50 +0100
Message-ID	<I9EhQ-btUj-3@gated-at.bofh.it>
In reply to	#267622

tomas@tuxteam.de composed on 2024-02-20 09:38 (UTC+0100):

> On Tue, Feb 20, 2024 at 02:42:18AM -0500, Felix Miata wrote:

>> Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):

>> > I just removed 3 snapshots from my daily driver with no change in used 
>> > space reported by df

>> df doesn't know how to calculate freespace on btrfs. You need to be typing

>> 	btrfs filesystem df

>> if you have not aliased df to btrfs filesystem df.

> Still, Keith seems to have a real shortage of file system free space,
> otherwise Debian upgrades wouldn't fail.

> I don't know much about btrfs, but what would be really helpful (if
> you do, and it seems so) would be for you to fill us in on how to
> asses the space used up by old snapshots (what seems to be the main
> suspect currently).

My hands-on experience with btrfs is limited to one laptop my brother gave me with
openSUSE installed that I only boot 2-3 times per year. My mentioning of the btrfs
command in this thread is based upon years of frequenting openSUSE and Fedora
mailing lists and forums. openSUSE made btrfs its default filesystem somewhere
around 7-8 years ago. I think Fedora made btrfs default more recently. Google &
DDG should be able to provide much better help than I on how to interpret btrfs
command output. So should support@lists.opensuse.org and
https://forums.opensuse.org/c/english/install-boot-login/18 and the comparable
Fedora forums. My own Gnu/Linux installations, other than Knoppix, have always
been on extX.

I suggest Keith's 36G / partition size must be a marginal for btrfs use. IIRC, 40G
may be the officially suggested minimum size for an openSUSE btrfs / filesystem
where /home/ is on a separate (xfs) filesystem. Keith has /home/ within /.

Surely somewhere on debian.org such things must be addressed if Bookworm's default
has also been changed to btrfs.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#267646

From	Greg Wooledge <greg@wooledge.org>
Date	2024-02-20 21:00 +0100
Message-ID	<I9Erv-btXt-13@gated-at.bofh.it>
In reply to	#267645

On Tue, Feb 20, 2024 at 02:47:26PM -0500, Felix Miata wrote:
> Surely somewhere on debian.org such things must be addressed if Bookworm's default
> has also been changed to btrfs.

That has not happened.  The default file system is still ext4.

[toc] | [prev] | [next] | [standalone]

#267650

From	Felix Miata <mrmazda@earthlink.net>
Date	2024-02-21 00:50 +0100
Message-ID	<I9I26-bwbM-1@gated-at.bofh.it>
In reply to	#267646

Greg Wooledge composed on 2024-02-20 14:56 (UTC-0500):

> On Tue, Feb 20, 2024 at 02:47:26PM -0500, Felix Miata wrote:

>> Surely somewhere on debian.org such things must be addressed if Bookworm's default
>> has also been changed to btrfs.

> That has not happened.  The default file system is still ext4.

I didn't think so, which begs the question why OP Keith is using it. :p
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#267655

From	Keith Bainbridge <keithrbau@gmail.com>
Date	2024-02-21 02:30 +0100
Message-ID	<I9JAR-bxaJ-1@gated-at.bofh.it>
In reply to	#267650

On 21/2/24 10:47, Felix Miata wrote:
> I didn't think so, which begs the question why OP Keith is using it. :p
> -- 

I read somewhere about 2 years ago,  that it automagically de-duped data 
when it detected I was copying the same file to different directories. 
It's not deliberate, but I have often found copies of my files amongst 
files I have backed up for my wife (where I have put copies of my 
important stuff occasionally.    And more common if I rsync a usb to a 
new destination - the usb I use at a volunteer job with portable apps on 
a foreign PC.   I found what I think was that article the other week; 
and it now talks about a manual process to de-dupe the data. I don't 
believe I could have skipped the most important paragraph in the 
article.     I prefer rdfind -makehardlinks.    Writing to btrfs feels 
quicker than ext4

But why use btrfs on a system partition. I like to try new stuff. Like I 
get a nagging thought of trying arch linux regularly. I resist 
mostly......   I should use sid as my daily driver, but I'm not good at 
asking for help; and I get the feeling that some people here would want 
to tell me something like 'I made my bed, lay in it.'

  So I make do with using developer versions of firefox & thunderbird 
and beta libreOffice (24.02 I think) They are on a separate partition 
from my system.

-- 
All the best

Keith Bainbridge

keith.bainbridge.3216@gmail.com
+61 (0)447 667 468

UTC + 10:00

[toc] | [prev] | [next] | [standalone]

#267656

From	<tomas@tuxteam.de>
Date	2024-02-21 06:50 +0100
Message-ID	<I9NEt-bzDq-1@gated-at.bofh.it>
In reply to	#267655

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 21, 2024 at 12:21:05PM +1100, Keith Bainbridge wrote:
> 
> On 21/2/24 10:47, Felix Miata wrote:
> > I didn't think so, which begs the question why OP Keith is using it. :p
> > -- 
> 
> I read somewhere about 2 years ago,  that it automagically de-duped data
> when it detected I was copying the same file to different directories [...]

I think the Wikipedia [1] is a good ref, at least at the level we are
discussing. 

Deduplication is mentioned there requiring userspace tools, so it seems
you'll have to run a process (as a daemon, from cron, whatever) to achieve
that.

It also mentions "reflinks", which is a kind of COW file copy (not to be
confused with a hardlink, which all civilised file systems have).

Cheers
[1] https://en.wikipedia.org/wiki/Btrfs#List_of_features
-- 
t

[toc] | [prev] | [next] | [standalone]

#267651

From	Felix Miata <mrmazda@earthlink.net>
Date	2024-02-21 01:40 +0100
Message-ID	<I9IOu-bwGc-15@gated-at.bofh.it>
In reply to	#267622

tomas@tuxteam.de composed on 2024-02-20 09:38 (UTC+0100):

> On Tue, Feb 20, 2024 at 02:42:18AM -0500, Felix Miata wrote:

>> Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):

>>> I just removed 3 snapshots from my daily driver with no change in used 
>>> space reported by df

>> df doesn't know how to calculate freespace on btrfs. You need to be typing

>> 	btrfs filesystem df

>> if you have not aliased df to btrfs filesystem df.

> Still, Keith seems to have a real shortage of file system free space,
> otherwise Debian upgrades wouldn't fail.

> I don't know much about btrfs, but what would be really helpful (if
> you do, and it seems so) would be for you to fill us in on how to
> asses the space used up by old snapshots (what seems to be the main
> suspect currently).

A current thread from elsewhere that should be helpful:
<https://forums.opensuse.org/t/btrfs-disk-full-how-to-fix-it-is-that-really-the-solution/172576>

	btrfs filesystem usage /
	snapper list
	btrfs qgroup show /

Was requested by a btrfs expert.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#267652

From	Keith Bainbridge <keithrbau@gmail.com>
Date	2024-02-21 02:00 +0100
Message-ID	<I9J7P-bwMp-1@gated-at.bofh.it>
In reply to	#267651

On 21/2/24 11:38, Felix Miata wrote:
> A current thread from elsewhere that should be helpful:
> <https://forums.opensuse.org/t/btrfs-disk-full-how-to-fix-it-is-that- 
> really-the-solution/172576>
> 
> 	btrfs filesystem usage /
> 	snapper list
> 	btrfs qgroup show /

Thanks for the prompt, Felix

   >> sudo btrfs filesystem usage /
[sudo] password for root:
Overall:
     Device size:		  70.00GiB   ===== remember I expanded this partition 
yesterday
     Device allocated:		  35.82GiB
     Device unallocated:		  34.18GiB
     Device missing:		     0.00B
     Device slack:		     0.00B
     Used:			  34.30GiB
     Free (estimated):		  34.90GiB	(min: 17.81GiB)
     Free (statfs, df):		  34.90GiB
     Data ratio:			      1.00
     Metadata ratio:		      2.00
     Global reserve:		  71.69MiB	(used: 0.00B)
     Multiple profiles:		        no

Data,single: Size:32.80GiB, Used:32.09GiB (97.82%)
    /dev/sda3	  32.80GiB

Metadata,DUP: Size:1.50GiB, Used:1.11GiB (73.77%)
    /dev/sda3	   3.00GiB

System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)
    /dev/sda3	  16.00MiB

Unallocated:
    /dev/sda3	  34.18GiB
keith@dell0 $

  Wed 21Feb2024@11:44:26
  :~

At least I can make sense from some of these output numbers

   >> sudo btrfs qgroup show /
ERROR: can't list qgroups: quotas not enabled
keith@dell0 $

  Wed 21Feb2024@11:47:13
  :~

installed snapper and
    >> sudo snapper list
The config 'root' does not exist. Likely snapper is not configured.
See 'man snapper' for further instructions.
keith@dell0 $

More to learn about, I see


-- 
All the best

Keith Bainbridge

keith.bainbridge.3216@gmail.com
+61 (0)447 667 468

UTC + 10:00

[toc] | [prev] | [next] | [standalone]

#267654

From	Felix Miata <mrmazda@earthlink.net>
Date	2024-02-21 02:20 +0100
Message-ID	<I9Jrb-bx7P-1@gated-at.bofh.it>
In reply to	#267652

Keith Bainbridge composed on 2024-02-21 11:57 (UTC+1100):
 
> Felix Miata wrote:

>> A current thread from elsewhere that should be helpful:
>> <https://forums.opensuse.org/t/btrfs-disk-full-how-to-fix-it-is-that- 
>> really-the-solution/172576>
 
>> 	btrfs filesystem usage /
>> 	snapper list
>> 	btrfs qgroup show /
 
> Thanks for the prompt, Felix
 
>    >> sudo btrfs filesystem usage /
> [sudo] password for root:
> Overall:
>      Device size:		  70.00GiB   ===== remember I expanded this partition 
> yesterday 

How? Did you resize the filesystem too?
<https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html#man-filesystem-resize>
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#267626

From	Keith Bainbridge <keithrbau@gmail.com>
Date	2024-02-20 11:20 +0100
Message-ID	<I9vod-boFb-1@gated-at.bofh.it>
In reply to	#267617

On 20/2/24 18:42, Felix Miata wrote:
> btrfs filesystem df

OK, so please interpret:

   >> btrfs filesystem df -h /
Data, single: total=32.80GiB, used=31.94GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=1.50GiB, used=1.10GiB
GlobalReserve, single: total=71.69MiB, used=0.00B
keith@dell0 $

  Tue 20Feb2024@20:57:45
  :~

   >> btrfs filesystem df -h /mnt/data/
Data, single: total=530.02GiB, used=329.55GiB
System, DUP: total=8.00MiB, used=112.00KiB
Metadata, DUP: total=5.00GiB, used=1.10GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
keith@dell0 $

when cfdisk reports:
  Device                            Start                End 
Sectors           Size Type
 >>  /dev/sda1                 2048         1667678207 
1667676160         795.2G Linux filesystem
     Free space                   1667678208         1785522175 
117843968          56.2G
     /dev/sda2                    1785522176         1786245119 
    722944           353M EFI System
     /dev/sda3                    1786245120         1933045759 
146800640            70G EFI System
     /dev/sda4                    1933045760         1953523711 
  20477952           9.8G Linux swap

To clarify
/dev/sda1 is /mnt/data    and I don't understand the 'EFI System' note
/dev/sda3 is /

Perhaps the explanation why the reports from btrfs filesystem df make no 
sense will come when I get into my assignment?

-- 
All the best

Keith Bainbridge

keith.bainbridge.3216@gmail.com
+61 (0)447 667 468

UTC + 10:00

[toc] | [prev] | [next] | [standalone]

#267630

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2024-02-20 12:40 +0100
Message-ID	<I9wDD-bpkJ-9@gated-at.bofh.it>
In reply to	#267626

Hi,

> when cfdisk reports:
> Device      Start       End          Sectors   Size  Type
> /dev/sda2   1785522176  1786245119     722944  353M  EFI System
> /dev/sda3   1786245120  1933045759  146800640  70G   EFI System
> I don't understand the 'EFI System' note /dev/sda3 is /

The partition type does not necessarily match the type of filesystem
which is currently in that partition. It's just a field in the
partition table which must have some value.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#267640

From	debian-user@howorth.org.uk
Date	2024-02-20 18:20 +0100
Message-ID	<I9BWF-bsFc-5@gated-at.bofh.it>
In reply to	#267617

Felix Miata <mrmazda@earthlink.net> wrote:
> Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):
> 
> > I just removed 3 snapshots from my daily driver with no change in
> > used space reported by df  
> 
> df doesn't know how to calculate freespace on btrfs. You need to be
> typing
> 
> 	btrfs filesystem df

df [options] <path>
           Show a terse summary information about allocation of block
           group types of a given mount point. The original purpose of
           this command was a debugging helper. The output needs to be
           further interpreted and is not suitable for quick overview.


FWIW my root filesystem is btrfs and I use the normal df command all the
time without a problem. I've never used btrfs filesystem df

[toc] | [prev] | [next] | [standalone]

#267579

From	Keith Bainbridge <keithrbau@gmail.com>
Date	2024-02-19 04:30 +0100
Message-ID	<I92vT-b77v-3@gated-at.bofh.it>
In reply to	#267570

On 19/2/24 10:26, 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 <keithrbau@gmail.com> 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.
> 
> 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.
> 
> So I'm starting a new thread on that topic.
> 
> 

So I'm back to see some more helpful hints. Thanks folk

I am convinced that the missing space is used by btrfs snapshot process. 
But WHY is the used space reporting on my daily driver LESS than that on 
the spare machine  29G vs 35G? The original install was the same .iso 
  Ah well

I could add some of the spare space the the / partition, but how much? 
Play safe and use the lot, making it 60G compared to 63G on my daily 
driver. (And create some free space off the data partition before it's 
too late.)

Just as well I have time on my hands

Again, thanks to all for your suggestions

-- 
All the best

Keith Bainbridge

keith.bainbridge.3216@gmail.com
+61 (0)447 667 468

UTC + 10:00

[toc] | [prev] | [next] | [standalone]

#267581

From	<tomas@tuxteam.de>
Date	2024-02-19 06:50 +0100
Message-ID	<I94Hn-b8oH-1@gated-at.bofh.it>
In reply to	#267579

[Multipart message — attachments visible in raw view] — view raw

On Mon, Feb 19, 2024 at 02:20:20PM +1100, Keith Bainbridge wrote:

[...]

> I am convinced that the missing space is used by btrfs snapshot process. But
> WHY is the used space reporting on my daily driver LESS than that on the
> spare machine  29G vs 35G? The original install was the same .iso  Ah well

Perhaps because you upgrade your daily driver more often? May be
because it has more packages installed?

Another post of yours upthread suggests that your upgrade process roughly
is:

 1. take snapshot
 2. upgrade

Do you remove your snapshots if/after all went well? (note that I
have no idea how snapshots are removed under btrfs and whether they
are somehow visible to "du" -- I guess the second is a "no").

If not, the space is taken by all the files which have been overwritten
in the upgrade process. More "versions", less space.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#267582

From	David Christensen <dpchrist@holgerdanske.com>
Date	2024-02-19 08:40 +0100
Message-ID	<I96pP-b9sU-7@gated-at.bofh.it>
In reply to	#267579

On 2/18/24 19:20, Keith Bainbridge wrote:
> I am convinced that the missing space is used by btrfs snapshot process.


Perhaps.  But, are you re-balancing your btrfs file systems regularly?

https://manpages.debian.org/bookworm/btrfs-progs/btrfs-balance.8.en.html


Doing it by hand was not practical for me.  I wrote a Perl script to 
automate the process.  On SSD's, the results were decent.  On USB flash 
drives, not so much.


Searching for a power tool today, I see:

2024-02-18 23:27:43 dpchrist@laalaa ~/stretch-amd64
$ apt-cache search btrfs | grep mainten
btrfsmaintenance - automate btrfs maintenance tasks on mountpoints or 
directories

https://packages.debian.org/bookworm/btrfsmaintenance


I suggest installing and trying the btrfsmaintenance package.


David

[toc] | [prev] | [next] | [standalone]

#267585

From	debian-user@howorth.org.uk
Date	2024-02-19 12:30 +0100
Message-ID	<I9a0p-bbGG-1@gated-at.bofh.it>
In reply to	#267582

David Christensen <dpchrist@holgerdanske.com> wrote:
> On 2/18/24 19:20, Keith Bainbridge wrote:
> > I am convinced that the missing space is used by btrfs snapshot
> > process.  
> 
> 
> Perhaps.  But, are you re-balancing your btrfs file systems regularly?
> 
> https://manpages.debian.org/bookworm/btrfs-progs/btrfs-balance.8.en.html

But does balancing a btrfs system actually recover any space? I think
not. It's eternally moving the deckchairs on the Titanic. (though with
a more useful purpose)

I'd recommend installing snapper if you haven't already.
https://wiki.archlinux.org/title/Snapper is helpful for using it.

[toc] | [prev] | [next] | [standalone]

#267615

From	Keith Bainbridge <keithrbau@gmail.com>
Date	2024-02-20 08:20 +0100
Message-ID	<I9sA1-bmXS-1@gated-at.bofh.it>
In reply to	#267579

On 19/2/24 14:20, Keith Bainbridge wrote:
> 
> On 19/2/24 10:26, 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 <keithrbau@gmail.com> 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.
>>
>> 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.
>>
>> So I'm starting a new thread on that topic.
>>
>>
> 
> So I'm back to see some more helpful hints. Thanks folk
> 
> I am convinced that the missing space is used by btrfs snapshot process. 
> But WHY is the used space reporting on my daily driver LESS than that on 
> the spare machine  29G vs 35G? The original install was the same .iso 
>   Ah well
> 
> I could add some of the spare space the the / partition, but how much? 
> Play safe and use the lot, making it 60G compared to 63G on my daily 
> driver. (And create some free space off the data partition before it's 
> too late.)
> 
> Just as well I have time on my hands
> 
> Again, thanks to all for your suggestions
> 

I am sure I saw a response to comment of mine, where I was misunderstood 
in the numbers I quoted for used space on my daily driver - 29G; and the 
space used by the problem machine - 35G.  There was a suggestion that I 
had not updated it as often as daily driver.    I had kept problem box 
as up to date as daily until a few days ago when it refused to update 
due to lack of space. This is when I discovered I had a problem. It is 
switched off at present, pending my deciding whether to expand / 
partition or re-install on the free space on ext4.   I will delete a few 
snapshots before I proceed, just to see what happens - I'll do that 
shortly, in fact, now I can see that it may have a bigger affect than I 
figured.

Now a minor amendment to my last note, where deleting snapshots has haad 
no bearing on used space.  Before I started, df reported 28G used, 
compared to 29G used yesterday. Remember my home is sym-linked from 
another partition. du is reporting /home is 3M which is the original 
/home/keith and re-named to keep it handy IN CASE I need it some day - 
like when I did some major surgery on that data partition the other 
week.  I'm trying to say that nothing I've done overnight has changed 
used space.  There were no packages to upgrade today.

df is now reporting 27G used on /   confirming btrfs seems to take time 
to reflect changes in snapshots.

Back later.

-- 
All the best

Keith Bainbridge

keith.bainbridge.3216@gmail.com
+61 (0)447 667 468

UTC + 10:00

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

partition reporting full, but not

Contents

#267617

#267622

#267628

#267629

#267645

#267646

#267650

#267655

#267656

#267651

#267652

#267654

#267626

#267630

#267640

#267579

#267581

#267582

#267585

#267615