MX Linux Forum

Support for MX and antiX Linux distros
https://www.forum.mxlinux.org/

little storage space conundrum

https://www.forum.mxlinux.org/viewtopic.php?t=79693

Page 1 of 1

little storage space conundrum

Posted: Mon Mar 11, 2024 10:30 am
by argonaut459

Code: Select all

System:    Kernel: 6.0.0-6mx-amd64 [6.0.12-1~mx21+1] x86_64 bits: 64 compiler: gcc v: 10.2.1 
           parameters: BOOT_IMAGE=/@/boot/vmlinuz-6.0.0-6mx-amd64 root=UUID=<filter> ro 
           rootflags=subvol=@ quiet splash 
           Desktop: Xfce 4.18.1 tk: Gtk 3.24.24 info: xfce4-panel, plank wm: xfwm 4.18.0 vt: 7 
           dm: LightDM 1.26.0 Distro: MX-21.3_ahs_x64 Wildflower September 18  2022 
           base: Debian GNU/Linux 11 (bullseye) 
Machine:   Type: Desktop Mobo: MSI model: Z97A GAMING 6 (MS-7917) v: 2.0 serial: <filter> 
           UEFI: American Megatrends v: 10.2 date: 08/11/2015 
CPU:       Info: Quad Core model: Intel Core i5-4690K bits: 64 type: MCP arch: Haswell family: 6 
           model-id: 3C (60) stepping: 3 microcode: 28 cache: L2: 6 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 27998 
           Speed: 3500 MHz min/max: 800/3500 MHz Core speeds (MHz): 1: 3500 2: 3500 3: 3500 
           4: 3500 
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled 
           Type: mds mitigation: Clear CPU buffers; SMT disabled 
           Type: meltdown mitigation: PTI 
           Type: mmio_stale_data status: Unknown: No mitigations 
           Type: retbleed status: Not affected 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: disabled, 
           RSB filling, PBRSB-eIBRS: Not affected 
           Type: srbds mitigation: Microcode 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: eVga.com. driver: nouveau v: kernel 
           bus-ID: 02:00.0 chip-ID: 10de:13c2 class-ID: 0300 
           Display: x11 server: X.Org 1.20.14 compositor: xfwm4 v: 4.18.0 driver: 
           loaded: modesetting unloaded: fbdev,vesa display-ID: :0.0 screens: 1 
           Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") 
           s-diag: 582mm (22.9") 
           Monitor-1: DVI-I-1 res: 1920x1080 hz: 60 dpi: 92 size: 531x298mm (20.9x11.7") 
           diag: 609mm (24") 
           OpenGL: renderer: NV124 v: 4.3 Mesa 22.0.5 direct render: Yes 
Audio:     Device-1: Intel 9 Series Family HD Audio vendor: Micro-Star MSI driver: snd_hda_intel 
           v: kernel bus-ID: 00:1b.0 chip-ID: 8086:8ca0 class-ID: 0403 
           Device-2: NVIDIA GM204 High Definition Audio vendor: eVga.com. driver: snd_hda_intel 
           v: kernel bus-ID: 02:00.1 chip-ID: 10de:0fbb class-ID: 0403 
           Sound Server-1: ALSA v: k6.0.0-6mx-amd64 running: yes 
           Sound Server-2: PulseAudio v: 14.2 running: yes 
Network:   Device-1: Qualcomm Atheros Killer E220x Gigabit Ethernet vendor: Micro-Star MSI 
           driver: alx v: kernel port: d000 bus-ID: 04:00.0 chip-ID: 1969:e091 class-ID: 0200 
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 2.96 TiB used: 443.45 GiB (14.6%) 
           SMART Message: Unable to run smartctl. Root privileges required. 
           ID-1: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB 
           block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> 
           rev: 2B6Q scheme: MBR 
           ID-2: /dev/sdb maj-min: 8:16 vendor: Toshiba model: DT01ACA200 size: 1.82 TiB 
           block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 7200 
           serial: <filter> rev: ABB0 scheme: MBR 
           ID-3: /dev/sdc maj-min: 8:32 vendor: Crucial model: CT1000MX500SSD1 size: 931.51 GiB 
           block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> 
           rev: 033 scheme: GPT 
Partition: ID-1: / raw-size: 453.71 GiB size: 453.71 GiB (100.00%) used: 443.45 GiB (97.7%) 
           fs: btrfs dev: /dev/sdc3 maj-min: 8:35 
           ID-2: /boot/efi raw-size: 100 MiB size: 98.4 MiB (98.42%) used: 562 KiB (0.6%) fs: vfat 
           dev: /dev/sdc1 maj-min: 8:33 
           ID-3: /home raw-size: 453.71 GiB size: 453.71 GiB (100.00%) used: 443.45 GiB (97.7%) 
           fs: btrfs dev: /dev/sdc3 maj-min: 8:35 
Swap:      Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default) 
           ID-1: swap-1 type: partition size: 24 GiB used: 0 KiB (0.0%) priority: -2 
           dev: /dev/sdc2 maj-min: 8:34 
Sensors:   System Temperatures: cpu: 29.8 C mobo: 27.8 C gpu: nouveau temp: 36.0 C 
           Fan Speeds (RPM): N/A gpu: nouveau fan: 678 
Repos:     Packages: 2477 note: see --pkg apt: 2471 lib: 1337 flatpak: 6 
           No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/brave-browser-release.list 
           1: deb [arch=amd64] https://brave-browser-apt-release.s3.brave.com/ bullseye main
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://debian.netcologne.de/debian/ bullseye-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://debian.netcologne.de/debian/ bullseye main contrib non-free
           2: deb http://security.debian.org/debian-security bullseye-security main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/lutris.list 
           1: deb https://download.opensuse.org/repositories/home:/strycore/Debian_11/ /
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://nl.mxrepo.com/mx/repo/ bullseye main non-free
           2: deb http://nl.mxrepo.com/mx/repo/ bullseye ahs
           Active apt repos in: /etc/apt/sources.list.d/spotify.list 
           1: deb http://repository.spotify.com stable non-free
           Active apt repos in: /etc/apt/sources.list.d/vivaldi.list 
           1: deb [arch=amd64] https://repo.vivaldi.com/stable/deb/ stable main
Info:      Processes: 246 Uptime: 28m wakeups: 1 Memory: 31.3 GiB used: 2.2 GiB (7.0%) 
           Init: SysVinit v: 2.96 runlevel: 5 default: 5 tool: systemctl Compilers: gcc: N/A 
           alt: 10 Client: shell wrapper v: 5.1.4-release inxi: 3.3.06 
Boot Mode: UEFI
Hi folks, got a little mystery for you before I erase it all and do a fresh MX23 install next week.
as you can see:
I got MX installed on

Code: Select all

ID-3: /dev/sdc maj-min: 8:32 vendor: Crucial model: CT1000MX500SSD1 size: 931.51 GiB 
           block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> 
           rev: 033 scheme: GPT
And it is recorded as full to the brim ~ 98%

Code: Select all

Partition: ID-1: / raw-size: 453.71 GiB size: 453.71 GiB (100.00%) used: 443.45 GiB (97.7%) 
           fs: btrfs dev: /dev/sdc3 maj-min: 8:35 
           ID-2: /boot/efi raw-size: 100 MiB size: 98.4 MiB (98.42%) used: 562 KiB (0.6%) fs: vfat 
           dev: /dev/sdc1 maj-min: 8:33 
           ID-3: /home raw-size: 453.71 GiB size: 453.71 GiB (100.00%) used: 443.45 GiB (97.7%) 
           fs: btrfs dev: /dev/sdc3 maj-min: 8:35
The weird part is, if I check used space in thunar: I get 17,4 GB for root and 88,7 GB for home. Which makes more sense than an occupied 443GB.

some terminal info:

Code: Select all

df -h
df: /run/user/1000/doc: Die Operation ist nicht erlaubt
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev             16G       0   16G    0% /dev
tmpfs           3,2G    2,8M  3,2G    1% /run
/dev/sdc3       454G    444G  9,8G   98% /
tmpfs           5,0M    8,0K  5,0M    1% /run/lock
tmpfs            12G    119M   11G    2% /dev/shm
/dev/sdc3       454G    444G  9,8G   98% /home
/dev/sdc1        99M    562K   98M    1% /boot/efi
cgroup           12K       0   12K    0% /sys/fs/cgroup
tmpfs           3,2G     12K  3,2G    1% /run/user/1000

Code: Select all

du -s -h * | sort -nr
584K	Calibre Library
272K	timeshift-autosnap-apt
176K	kodi_crashlog-20230212_001636.log
173M	jdownloader
88K	System.html
20K	Schreibtisch
14G	Videos
14G	Dokumente
8,0K	nano.save
6,0M	Bilder
6,0G	Downloads
4,2G	MediathekView
4,0K	Schreibtisch (symlink)
4,0K	PlayOnLinux's virtual drives
2,9M	sysinfo_crash_20230930.zip
1,6G	Musik
1,2G	Games
0	Vorlagen
0	Öffentlich
0	Documents
0	Calibre-Bibliothek
and of root

Code: Select all

sudo du -s -h * | sort -nr
[sudo] Passwort für punisher:     
du: Zugriff auf 'proc/8593/task/8593/fd/4' nicht möglich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf 'proc/8593/task/8593/fdinfo/4' nicht möglich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf 'proc/8593/fd/3' nicht möglich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf 'proc/8593/fdinfo/3' nicht möglich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf 'run/user/1000/doc' nicht möglich: Keine Berechtigung
du: Zugriff auf 'run/user/1000/gvfs' nicht möglich: Keine Berechtigung
457M	boot.backup
457M	boot
94M	root
89G	home
39M	etc
16K	tmp
9,3G	usr
4,7G	var
4,0K	vmlinuz.old
4,0K	vmlinuz
4,0K	sbin
4,0K	libx32
4,0K	lib64
4,0K	lib
4,0K	initrd.img.old
4,0K	initrd.img
4,0K	bin
2,8M	run
1,6G	opt
0	sys
0	pulse
0	proc
0	mnt
0	media
0	dev
These also make way more sense than the reported used up space.

Whats going on here? How would I found out what is actually hogging up all that space?
I know, kind of a mute question as I'm about to reformat the whole SSD, but still something I can't wrap my head around.
Is it cause of the BTRFS and subvolumes? Is it cause of the borked up OS install on the other half of the SSD?

I'd appreciate it if someone could tell me how to find out what is happining here.
Cheers, and have a great start into the week.

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 10:59 am
by j2mcgreg
What the QSI is reporting is that 100% of the drive has been allocated to the Primary partition and then it goes on to report on how the Primary has been subdivided into /esp. /root and /home partitions. The usage figures are for how much data has been written to these secondary partitions.

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 11:18 am
by argonaut459
Sorry I don't really understand what you mean.
So you tell me, that thunar and all others are reporting 443 GB used cause that is the AMOUNT of data that has been written to it?
Like in the "guaranteed TBW (Total Bytes Written)" of a manufacturer?

If so, smartctl gives me a
TBW of either 103,74 TB (if considering 4096 bytes sector size)
or 12,97 TB (considering 512 bytes sector size)
with the ~ 13 TB written being more what I "feel" about the drive as I think I mainly used to play with Linux and a few other things over the last couple years.

Or did I totally misunderstand you?

EDIT:
using conky with the predefined command

Code: Select all

${color}root:${alignr}${fs_used /} ${color3} /${color} ${fs_size /}
states the 443GB used, too. That was the first I saw it and figured something has be up.

On the laptop of my GF with ext4 and a / and /home partition conky reports these used sizes correct

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 11:40 am
by dolphin_oracle
maybe check with a btrfs specific tool. its possible the data is just reported incorrectly by the usual tools.

Code: Select all

btrfs filesystem df /
I think should do it.

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 11:42 am
by argonaut459

Code: Select all

$ btrfs filesystem df /
Data, single: total=446.01GiB, used=440.99GiB
System, single: total=4.00MiB, used=64.00KiB
Metadata, single: total=3.01GiB, used=1.99GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
I have to admit, I don't know what that is telling me now.

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 11:59 am
by dolphin_oracle
hmm maybe wrong command.

try

Code: Select all

btrfs filesystem show /

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 11:59 am
by DukeComposed
argonaut459 wrote: Mon Mar 11, 2024 11:42 am

Code: Select all

$ btrfs filesystem df /
Data, single: total=446.01GiB, used=440.99GiB
System, single: total=4.00MiB, used=64.00KiB
Metadata, single: total=3.01GiB, used=1.99GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
I have to admit, I don't know what that is telling me now.
Because you're using btrfs, there are a few different btrfs commands you can use.

"sudo btrfs filesystem show /" and "sudo btrfs filesystem show /home" can also tell you the total amount of space used by a given subvolume if you provide its mountpoint. gparted can also give you this same information.

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 12:04 pm
by argonaut459

Code: Select all

Label: 'XFCE'  uuid: 7a86bd5b-d3a6-45ae-9a0d-45b813ee884f
	Total devices 1 FS bytes used 442.97GiB
	devid    1 size 453.71GiB used 449.02GiB path /dev/sdc3

punisher@mxXFCE:/
$ sudo btrfs filesystem show /home
Label: 'XFCE'  uuid: 7a86bd5b-d3a6-45ae-9a0d-45b813ee884f
	Total devices 1 FS bytes used 442.97GiB
	devid    1 size 453.71GiB used 449.02GiB path /dev/sdc3
yet still. even if I make a luckyBackup backup, they are rather the ~18GB and ~88GB that thunar and the normal du command show.
I would not bother of this, if it showed like that from the very start - I only started paying attention when my browser startet stuttering a bit, and especially downloadprograms like jdownloader telling me that my drive is full.

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 12:13 pm
by DukeComposed
argonaut459 wrote: Mon Mar 11, 2024 12:04 pm yet still. even if I make a luckyBackup backup, they are rather the ~18GB and ~88GB that thunar and the normal du command show.
Bear in mind btrfs is no ordinary file system. It stores more than just files. You also need to consider the space that snapshots consume. 88 GiB may not seem like much, but on a 440-ish GiB partition you can only have five of them before you run out of space. "du -s /home" should show you the largest directories under /home if there's more than one user on the machine. If you only have 88 GiB in one /home directory but there's still a missing 400 GiB of consumed space, it's probably snapshots.

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 12:38 pm
by j2mcgreg
There's something else that may be adding to your confusion. Prior to 2008, a gigabyte (GB) equalled a thousand and twenty-four megabytes, but in that year the IEC redefined it as 1 GB = 1000 MB and renamed the former designation a Gibbybyte (GiB).
The folks that create bioses and Linux developers stayed with the mathematically correct GiB format while the computer manufacturers immediately switched to the new GB definition. It's really easy for an average user to confuse the two definitions IE your computer was advertised as having 500 GB storage but the bios and QSI say that it has 488 GiB. John Q. Public rarely notices the 'i' and then wonders where the extra space went --> it's there, he just isn't experienced enough yet to see it.

In your post (above) you say:
If so, smartctl gives me a
TBW of either 103,74 TB (if considering 4096 bytes sector size)
or 12,97 TB (considering 512 bytes sector size)
with the ~ 13 TB written being more what I "feel" about the drive as I think I mainly used to play with Linux and a few other things over the last couple years.
It's because Thunar and smartctl use the TiB and GiB definitions while hard drive manufacturers use TB and GB respectively.
1 tebibyte = 1.09951 terabytes

See here for a more extensive explanation:
https://www.techtarget.com/searchstorag ... bibyte-TiB

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 12:51 pm
by argonaut459
DukeComposed wrote: Mon Mar 11, 2024 12:13 pm it's probably snapshots.
Now thats an idea. Opening timeshift, I got 6 Snapshots
3 I made after the initial install steps (totally fresh, setup like it want it, yada yada yada) and 3 automatic ones from the last updates. Considering the 3 last updates all probably have the 88GB /home filesize, and the first manually made are smaller. It kind of adds up to easily 370GB currently used by last few snapshots + current home + current /

I never considered these, as I never saw a snapshot folder, like I do on my GF laptop that is running ext4

....

than again ..... I can't recall setting up timeshift to save / and /home during automatic ones, but than again, maybe thats BTRFS.
If I delete one of the most recent ones, I should free up roughly 88GB, right?

Let's try that :)

EDIT:

No, that didn't work
I checked the files via timeshift program, that opened the snapshot in a root thunar.
19,1GB root +149,7 GB /home = 168,8GB
after deleting this one snapshot, I should have roughly 271,2GB used

Nope

Code: Select all

 sudo btrfs filesystem show /
[sudo] Passwort für punisher:     
Label: 'XFCE'  uuid: 7a86bd5b-d3a6-45ae-9a0d-45b813ee884f
	Total devices 1 FS bytes used 441.69GiB
	devid    1 size 453.71GiB used 449.02GiB path /dev/sdc3

punisher@mxXFCE:~
$ sudo btrfs filesystem show /home
Label: 'XFCE'  uuid: 7a86bd5b-d3a6-45ae-9a0d-45b813ee884f
	Total devices 1 FS bytes used 441.69GiB
	devid    1 size 453.71GiB used 449.02GiB path /dev/sdc3

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 1:05 pm
by MXRobo
Just curious, does lsblk -f help at all?
Although I know it's not directly related to btrfs's peculiarities.
EDIT btrfs's snapshots maybe.

Re: little storage space conundrum

Posted: Mon Mar 11, 2024 1:20 pm
by DukeComposed
argonaut459 wrote: Mon Mar 11, 2024 12:51 pm I never considered these, as I never saw a snapshot folder, like I do on my GF laptop that is running ext4

than again ..... I can't recall setting up timeshift to save / and /home during automatic ones, but than again, maybe thats BTRFS.
If I delete one of the most recent ones, I should free up roughly 88GB, right?

Let's try that :)

EDIT:

No, that didn't work
"sudo btrfs subvolume list /home" should give you a list of the snapshots under /home and their path locations, which are probably defined by Timeshift. I'm sorry, I don't know how Timeshift names btrfs snapshots. I know that ZFS performs incremental snapshots, meaning if I have 88 GiB of data and I make one snapshot, then add 2 more GiB of data and snapshot it again, the second snapshot would only store the difference between the first snapshot and the second snapshot. So I'd have two snapshots of 88 and 2 GiB, respectively.

I'm going to guess btrfs snapshots work similarly, but again, I'm not too familiar with btrfs or how Timeshift uses it. If "sudo btrfs subvolume list /something" for / or for /home give you a list of different subvolumes with paths that don't match what you've assigned in /etc/fstab, I think you can check how much space each subvolume snapshot is consuming with "sudo du -sh pathname", where the pathname is shown in "sudo btrfs subvolume" relative to the /something it was given.

Re: little storage space conundrum

Posted: Tue Mar 12, 2024 6:39 am
by argonaut459
MXRobo wrote: Mon Mar 11, 2024 1:05 pm Just curious, does lsblk -f help at all?

Code: Select all

lsblk -f
NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                         
├─sda1
│    ntfs         Programme
│                       3C1C039A1C034DF8                                    
├─sda2
│    ntfs         Daten 8E141E9F141E89FB                                    
└─sda3
     ntfs         Downloads
                        BEBA1F77BA1F2C01                                    
sdb                                                                         
├─sdb1
│    ntfs         System-reserviert
│                       DCDC6BDDDC6BB106                                    
├─sdb2
│    ntfs         Windows
│                       B4527FE2527FA7AE                                    
└─sdb3
     ntfs         SchnellProgramme
                        7406B93A06B8FE64                                    
sdc                                                                         
├─sdc1
│    vfat   FAT32 EFI System
│                       3616-8F68                              97,9M     1% /boot/efi
├─sdc2
│    swap   1     swap  e8c81ca5-fd29-406a-a2c7-cc31daf4f878                [SWAP]
├─sdc3
│    btrfs        XFCE  7a86bd5b-d3a6-45ae-9a0d-45b813ee884f   10,9G    97% /home
└─sdc4
     btrfs        KDE   0d027b95-242b-48ba-ba87-826a479cdaae                
sr0
I'd say that doesn't show us anything new. :(

Code: Select all

sudo btrfs subvolume list /home
[sudo] Passwort für punisher:     
ID 256 gen 979711 top level 5 path @
ID 257 gen 979711 top level 5 path @home
ID 271 gen 977720 top level 5 path timeshift-btrfs/snapshots/2022-12-31_19-20-09/@
ID 489 gen 977720 top level 5 path timeshift-btrfs/snapshots/2023-01-20_15-17-25/@
ID 490 gen 41472 top level 5 path timeshift-btrfs/snapshots/2023-01-20_15-17-25/@home
ID 1102 gen 977720 top level 5 path timeshift-btrfs/snapshots/2023-07-24_21-30-17/@
ID 1103 gen 423402 top level 5 path timeshift-btrfs/snapshots/2023-07-24_21-30-17/@home
ID 1295 gen 977720 top level 5 path timeshift-btrfs/snapshots/2023-12-16_19-47-42/@
ID 1296 gen 773869 top level 5 path timeshift-btrfs/snapshots/2023-12-16_19-47-42/@home
ID 1432 gen 977720 top level 5 path timeshift-btrfs/snapshots/2024-02-15_20-00-46/@
ID 1433 gen 977760 top level 5 path timeshift-btrfs/snapshots/2024-02-15_20-00-46/@home
my /etc/fstab

Code: Select all

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>

/dev/sdc3	/	btrfs	subvol=@,ssd,discard=async,noatime	1	1
#Entry for /dev/sdc1 :
UUID=3616-8F68	/boot/efi	vfat	noatime,dmask=0002,fmask=0113	0	0
/dev/sdc3	/home	btrfs	subvol=@home,ssd,discard=async,noatime	1	2
#Entry for /dev/sdc2 :
UUID=e8c81ca5-fd29-406a-a2c7-cc31daf4f878	swap	swap	noatime	1	2
sorry, the pathname command somehow doesn't get me anything. Always says file or directory not found. Here a few tries with the last timeshift entry in the list.

Code: Select all

ID 1432 gen 977720 top level 5 path timeshift-btrfs/snapshots/2024-02-15_20-00-46/@
ID 1433 gen 977760 top level 5 path timeshift-btrfs/snapshots/2024-02-15_20-00-46/@home
punisher@mxXFCE:~
$ sudo du -sh path timeshift-btrfs/snapshots/2024-02-15_20-00-46/@home
du: Zugriff auf 'path' nicht möglich: Datei oder Verzeichnis nicht gefunden
du: Zugriff auf 'timeshift-btrfs/snapshots/2024-02-15_20-00-46/@home' nicht möglich: Datei oder Verzeichnis nicht gefunden
punisher@mxXFCE:~
$ sudo du -sh timeshift-btrfs/snapshots/2024-02-15_20-00-46/@home
du: Zugriff auf 'timeshift-btrfs/snapshots/2024-02-15_20-00-46/@home' nicht möglich: Datei oder Verzeichnis nicht gefunden
punisher@mxXFCE:~
$ sudo du -sh timeshift-btrfs/snapshots/2024-02-15_20-00-46
du: Zugriff auf 'timeshift-btrfs/snapshots/2024-02-15_20-00-46' nicht möglich: Datei oder Verzeichnis nicht gefunden
If the timeshift snapshots took up al the space, deleting one should have freed up some space, right? Cause it didn't yesterday.

Re: little storage space conundrum

Posted: Tue Mar 12, 2024 7:42 am
by DukeComposed
argonaut459 wrote: Tue Mar 12, 2024 6:39 am

Code: Select all

sudo btrfs subvolume list /home
[sudo] Passwort für punisher:     
ID 256 gen 979711 top level 5 path @
ID 257 gen 979711 top level 5 path @home
ID 271 gen 977720 top level 5 path timeshift-btrfs/snapshots/2022-12-31_19-20-09/@
ID 489 gen 977720 top level 5 path timeshift-btrfs/snapshots/2023-01-20_15-17-25/@
ID 490 gen 41472 top level 5 path timeshift-btrfs/snapshots/2023-01-20_15-17-25/@home
ID 1102 gen 977720 top level 5 path timeshift-btrfs/snapshots/2023-07-24_21-30-17/@
ID 1103 gen 423402 top level 5 path timeshift-btrfs/snapshots/2023-07-24_21-30-17/@home
ID 1295 gen 977720 top level 5 path timeshift-btrfs/snapshots/2023-12-16_19-47-42/@
ID 1296 gen 773869 top level 5 path timeshift-btrfs/snapshots/2023-12-16_19-47-42/@home
ID 1432 gen 977720 top level 5 path timeshift-btrfs/snapshots/2024-02-15_20-00-46/@
ID 1433 gen 977760 top level 5 path timeshift-btrfs/snapshots/2024-02-15_20-00-46/@home
These are your subvolumes. Clearly there's a timeshift-btrfs/snapshots subvolume beneath /home.
sorry, the pathname command somehow doesn't get me anything. Always says file or directory not found. Here a few tries with the last timeshift entry in the list.
"pathname" isn't a command. I used it as a placeholder for running commands like, for example, "sudo btrfs filesystem du /path/to/some/subvolume/snapshot". Always check "btrfs help" for exact syntax if you aren't sure or if someone on an online forum gives you contradictory instructions, because I could always be misremembering something.

Code: Select all

$ sudo du -sh path timeshift-btrfs/snapshots/2024-02-15_20-00-46/@home
$ sudo du -sh timeshift-btrfs/snapshots/2024-02-15_20-00-46/@home
$ sudo du -sh timeshift-btrfs/snapshots/2024-02-15_20-00-46
du: Zugriff auf 'timeshift-btrfs/snapshots/2024-02-15_20-00-46' nicht möglich: Datei oder Verzeichnis nicht gefunden
If the timeshift snapshots took up al the space, deleting one should have freed up some space, right? Cause it didn't yesterday.
Das ist nicht sehr gut. Ent schuldegang Sie. I don't think timeshift is going to put /home snapshots under ~.

The one thing I haven't seen yet is the output when you run "sudo ls -la /home". I really think that if timeshift-btrfs is a subvolume of /home, you should check for the presence of /home/timeshift-btrfs and run du against it. You have a good understanding of the tools to track disk usage, you just need to find the right path where timeshift is keeping its snapshots. It should be "path you gave to the 'btrfs subvolume list' command" + "/" + "path of the listed subvolume".

Edit: fixed quoting

Re: little storage space conundrum

Posted: Tue Mar 12, 2024 11:04 am
by MXRobo
Thanks - I wondered if lsblk -f would work with btrfs - I know nothing about it.

Re: little storage space conundrum

Posted: Tue Mar 12, 2024 11:49 am
by argonaut459
Well if I open a snapshot in timeshift, thunar says it is in this location
/run/timeshift/100755/backup/timeshift-btrfs/snapshots/

as I said, I already deleted one of the 3, yet it didn't change the used space on the partition

Re: little storage space conundrum

Posted: Tue Mar 12, 2024 12:52 pm
by DukeComposed
argonaut459 wrote: Tue Mar 12, 2024 11:49 am Well if I open a snapshot in timeshift, thunar says it is in this location
/run/timeshift/100755/backup/timeshift-btrfs/snapshots/

as I said, I already deleted one of the 3, yet it didn't change the used space on the partition
And what are the sizes of those subvolumes? As I said, if btrfs performs incremental backups, the amount of data a snapshot consumes may not be the same size as the data in that snapshot if there are existing snapshots that also contain the same content.

Re: little storage space conundrum  [Solved]

Posted: Sun Mar 17, 2024 1:26 am
by argonaut459
argonaut459 wrote: Mon Mar 11, 2024 12:51 pm
DukeComposed wrote: Mon Mar 11, 2024 12:13 pm
No, that didn't work
I checked the files via timeshift program, that opened the snapshot in a root thunar.
19,1GB root +149,7 GB /home = 168,8GB
after deleting this one snapshot, I should have roughly 271,2GB used
As I said earlier, the latest snapshot was about 170GB.

With MX23 I switched over to ext4, let's wait and see if the issue arises there too. Than it might be a wrong setting in the automated timeshift snaptshot script.
All times are UTC-04:00
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited