Announcement

**oshunluvr** · Dec 03, 2024, 10:51 AM

Not seeing this here. Snapshots take nearly zero time to make or delete. Sounds like a timeshift problem to me. Not sure why fstab options would cause a timeshift delay. I've never used timeshift.

My / mount options show as: rw,noatime,compress=lzo,ssd,discard=async,space_ca che=v2,autodefrag,subvolid=901,subvol=/@KDEneon

I have no guess about the extra space usage because you didn't say how you measured it. If you used sudo btrfs fi du -s <subvolume> to check space used then you're likely correct. Otherwise, probably not.

Also the type of compression you used could make a difference also. Some files are not compressible and actually can get larger when compression is forced. Although I doubt you'd eat up 6G of space that way.

Have you run scrub and/or balance lately?

**jfabernathy** · Dec 03, 2024, 12:27 PM

Thanks, if I do manual snapshots on this system it's instantaneous. it seems to be some delay in timeshift on *buntu.

The size I compare with du -h.

This is a new install so I'm assuming scub/balance is not an issue at this point.

**oshunluvr** · Dec 03, 2024, 12:34 PM

My first suspicion is using "du" instead of "sudo btrfs fi du -s <subvolume>".

Did the whole file system increase in size or just the subvolume?

Try the btrfs du on all your subvolumes and have a look at where the space is used. Maybe the forced compression broke reflinks??

cd into your subvolume and/or snapshot folders and run:

sudo btrfs fi du -s *

**jfabernathy** · Dec 03, 2024, 12:37 PM

I miss typed.

Code:

df -h

is what I used

**oshunluvr** · Dec 03, 2024, 12:45 PM

You should use: sudo btrfs fi df /

**jfabernathy** · Dec 03, 2024, 12:50 PM

Code:

jim@nucboxg3:~$ sudo btrfs fi df /
[sudo] password for jim:
Data, single: total=20.01GiB, used=17.14GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=708.86MiB
GlobalReserve, single: total=49.41MiB, used=0.00B
jim@nucboxg3:~$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.6G 2.1M 1.6G 1% /run
/dev/nvme0n1p2 460G 19G 441G 5% /
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 5.0M 16K 5.0M 1% /run/lock
efivarfs 192K 99K 89K 53% /sys/firmware/efi/efivars
tmpfs 7.7G 3.6M 7.7G 1% /tmp
/dev/nvme0n1p2 460G 19G 441G 5% /home
/dev/nvme0n1p1 300M 7.8M 292M 3% /boot/efi
tmpfs 1.6G 92K 1.6G 1% /run/user/1000

Next time I do an install, I use both commands before I compress.

**jfabernathy** · Dec 03, 2024, 01:28 PM

I found something over on the Fedora forum. where a person had the same 1 minute delay issue.

This happens probably because of the notification that Timeshift tries to show (but it doesn’t work), and it stalls the process for a bit.

Notice when you take a snapshot, a notify-send process is run as root:

notify-send -t 10000 -u low -i gtk-dialog-info TimeShift BTRFS Snapshot saved successfully (0s) -h string:desktop-entry:timeshift-gtk

This stalls the timeshift process until the notify-send process ends.

What is puzzling to me is when I test this on Linux Mint 22, which is based on Ubuntu 24.04, timeshift has no delay. Of course the Mint folks now own timeshift along with Cinnamon

**jfabernathy** · Dec 03, 2024, 02:13 PM

So I did a reinstall on real hardware.

Code:

jim@nucboxg3:~$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.6G 2.1M 1.6G 1% /run
/dev/nvme0n1p2 477G 6.3G 469G 2% /
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 5.0M 16K 5.0M 1% /run/lock
efivarfs 192K 99K 89K 53% /sys/firmware/efi/efivars
tmpfs 7.7G 4.0K 7.7G 1% /tmp
/dev/nvme0n1p2 477G 6.3G 469G 2% /home
/dev/nvme0n1p1 500M 7.8M 492M 2% /boot/efi
tmpfs 1.6G 68K 1.6G 1% /run/user/1000

jim@nucboxg3:~$ sudo btrfs fi df -h /
[sudo] password for jim:
Data, single: total=8.01GiB, used=5.81GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=199.27MiB
GlobalReserve, single: total=14.95MiB, used=0.00B

Now I'm going to modify fstab to add noatime and compress=zstd to both @ and @home subvols.

after I rebooted:

Code:

jim@nucboxg3:~$ mount | grep nvme
/dev/nvme0n1p2 on / type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,spac e_cache=v2,subvolid=256,subvol=/@)
/dev/nvme0n1p2 on /home type btrfs (rw,noatime,compress=zstd:3,ssd,discard=async,spac e_cache=v2,subvolid=257,subvol=/@home)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,io charset=iso8859-1,shortname=mixed,errors=remount-ro)

jim@nucboxg3:~$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.6G 2.1M 1.6G 1% /run
/dev/nvme0n1p2 477G 6.5G 469G 2% /
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 5.0M 16K 5.0M 1% /run/lock
efivarfs 192K 99K 89K 53% /sys/firmware/efi/efivars
tmpfs 7.7G 4.0K 7.7G 1% /tmp
/dev/nvme0n1p2 477G 6.5G 469G 2% /home
/dev/nvme0n1p1 500M 7.8M 492M 2% /boot/efi
tmpfs 1.6G 68K 1.6G 1% /run/user/1000

jim@nucboxg3:~$ sudo btrfs fi df -h /
[sudo] password for jim:
Data, single: total=9.01GiB, used=6.08GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=204.61MiB
GlobalReserve, single: total=15.73MiB, used=0.00B

jim@nucboxg3:~$ sudo btrfs fi defragment / -r -czstd

jim@nucboxg3:~$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.6G 2.1M 1.6G 1% /run
/dev/nvme0n1p2 477G 4.2G 471G 1% /
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 5.0M 16K 5.0M 1% /run/lock
efivarfs 192K 99K 89K 53% /sys/firmware/efi/efivars
tmpfs 7.7G 4.0K 7.7G 1% /tmp
/dev/nvme0n1p2 477G 4.2G 471G 1% /home
/dev/nvme0n1p1 500M 7.8M 492M 2% /boot/efi
tmpfs 1.6G 68K 1.6G 1% /run/user/1000

jim@nucboxg3:~$ sudo btrfs fi df -h /
Data, single: total=9.00GiB, used=3.71GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=218.52MiB
GlobalReserve, single: total=16.11MiB, used=0.00B

Not sure I understand the df -h and btrfs fi df -h / output, but it went down this time.

**jfabernathy** · Dec 03, 2024, 02:51 PM

So this is interesting. On my second install where I did the modify of fstab and btrfs fi defragment the sizes went down. BTW I didn't do any app installs before I did the adding of compression.

Before
/dev/nvme0n1p2 477G 6.5G 469G 2% /
Data, single: total=9.01GiB, used=6.08GiB

After
/dev/nvme0n1p2 477G 4.2G 471G 1% /
Data, single: total=9.00GiB, used=3.71GiB

Next when I installed timeshift, it worked as I would expect. It created a snapshot in under a second.

**jfabernathy** · Dec 03, 2024, 03:29 PM

so I kept installing packages one at a time taking timeshift snapshots after each install. After a few I got back to having a 1 minute long snapshot. So I did a snapshot from the command line using timeshift and it looks like this:

Code:

sudo timeshift --create --comments "snapshot with CLI"
Using system disk as snapshot device for creating snapshots in BTRFS mode
Mounted '/dev/nvme0n1p2' at '/run/timeshift/3181/backup'
btrfs: Quotas are not enabled
Creating new backup...(BTRFS)
Saving to device: /dev/nvme0n1p2, mounted at path: /run/timeshift/3181/backup
Created directory: /run/timeshift/3181/backup/timeshift-btrfs/snapshots/2024-12-03_16-20-58
Created subvolume snapshot: /run/timeshift/3181/backup/timeshift-btrfs/snapshots/2024-12-03_16-20-58/@
Created subvolume snapshot: /run/timeshift/3181/backup/timeshift-btrfs/snapshots/2024-12-03_16-20-58/@home
Created control file: /run/timeshift/3181/backup/timeshift-btrfs/snapshots/2024-12-03_16-20-58/info.json
BTRFS Snapshot saved successfully (0s)
Tagged snapshot '2024-12-03_16-20-58': ondemand
------------------------------------------------------------------------------

It was instant but after the

Code:

BTRFS Snapshot saced successfully (0s)

message I had to wait 60 seconds before the message

Code:

Tagged snapshot '2024-12-3_16-20-58': ondemand

appeared. So maybe the problem the Fedora forum mentioned is the problem here. It looks harmless, but annoying.

**claydoh** · Dec 03, 2024, 05:32 PM

I have not noticed any delay, though I have not looked at it, or noticed anything.
Manual snapshots are nearly instant, and my scheduled ones (daily/boot/weekly) I have never ever noticed taking place.
Deletions are instant as well.
I am not using any fancy-schmancy mount options, just whatever the kernel uses as default for btrfs(rw,relatime,ssd,discard=async,space_cache=v2)

**jfabernathy** · Dec 03, 2024, 05:38 PM

I went back to a new build on the same hardware with Linux Mint 22 which is also build on Ubuntu 24.04 LTS and use the same version of timeshift. I did the same software installation with the same sort of snapshots. I also changed over to compress=zstd soon after install the same as on neon.

However I never see the delay. It definitely a delay in the notification system.

**claydoh** · Dec 03, 2024, 06:28 PM

I have been using Timeshift on neon for a number of years now and have never noticed this.

Originally posted by jfabernathy View Post

Linux Mint 22 which is also build on Ubuntu 24.04 LTS and use the same version of timeshift.

No, Mint, who now own/develop Timeshift, has 24.06.3 in Mint 22, while Ubuntu 24.04 comes with 24.01.1, so there is some possibility of this being relevant.

(You can get 24.06.3 in Ubuntu via their PPA. You can ignore the "daily build" moniker, since that part is now inaccurate. I haven't bothered, myself.)

**jfabernathy** · Dec 03, 2024, 07:05 PM

Might be worth a test with the ppa version. I still have the neo build. I keep a stack of nvme ssd's around and swap them depending on what I'm testing. My Nucbox G3 has a snap off lid for access to the nvme and ram. I also don't have any issues with timeshift on my LMDE 6 system, so I need to check what version of timeshift it's using.

From a btrfs snapshot perspective I really prefer Endeavor OS (Archlinux) with snapper, snap-pac, grub-btrfs, and btrfs-assistant. Btrfs Assistant is a gui just like timeshift, except it also can configure snapper the right way. It's restore method is better than the snapper rollback method. I also like the read-only snapshots. which are bootable and uses an OverlayFS so you can test the booted snapshot, but no changes are saved.

Announcement

btrfs timeshift questions on latest KDE neon

btrfs timeshift questions on latest KDE neon

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment