timeshift: "not enough disk space" when destination is btrfs raid1

[MikeB5027]

Describe the bug When the destination filesystem is a btrfs raid1 disk array, selecting 'Settings - Location' in the Timeshift GUI results in a disk space error, despite there being plenty of space available.

To Reproduce Steps to reproduce the behavior:

1. Create a mirrored btrfs filesystem: mkfs.btrfs -d raid1 -m raid1 /dev/sdb /dev/sde
2. Mount the primary disk on /backup: mount /dev/sdb /backup
3. Configure Timeshift to use rsync with /dev/sdb as destination.
4. Start Timeshift and select 'Settings - Location'
5. Timeshift reports 'Not enough disk space (<1,000 MB)' even though there is plenty of space in the btrfs filesystem: (Image1)
6. Click OK and it reports '0 B Available /dev/sde': (Image2)
7. It has selected the mirror disk rather than the primary.
8. Quit out of Timeshift, select 'No' to 'Select another device?' and restart it.
9. It correctly reports '1.2 TB Available /dev/sdb': (Image3) The confusion probably arises from both disks having the same UUID, but they have different UUID_SUBs, as reported by blkid:

root@mint21:~# blkid /dev/sdb /dev/sde
/dev/sdb: UUID="6b5f43c8-e1c1-4aa8-8b9e-ea70936bdfda" UUID_SUB="f238470e-8b33-4a30-9d64-6b2d70ec2e79" TYPE="btrfs"
/dev/sde: UUID="6b5f43c8-e1c1-4aa8-8b9e-ea70936bdfda" UUID_SUB="b773913c-213f-4355-890a-6483137c9f42" TYPE="btrfs"

root@mint21:~# btrfs filesystem show /backup
Label: none  uuid: 6b5f43c8-e1c1-4aa8-8b9e-ea70936bdfda
    Total devices 2 FS bytes used 701.90GiB
    devid    1 size 1.82TiB used 764.01GiB path /dev/sdb
    devid    2 size 1.82TiB used 764.01GiB path /dev/sde

Expected behavior Timeshift Settings - Location should show the correct filesystem available capacity.

Screenshots Image1: Image2: Image3:

[MikeB5027]

Hi, I hope you don't mind but I tried to get my head around this myself, and I fear it might be an upstream bug. In Utility/Device.vala:1664 it tries to resolve the UUID by referring to /dev/disk/by-uuid, but that shows sde instead of sdb:

mike@mint2:/data/linux/mint$ ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Jul 22 12:30 0400acc7-c9ad-45a9-9098-c1ebff3c54c9 -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jul 22 12:30 1cbc1308-3f65-438d-8a27-0b05e7f201c2 -> ../../dm-4
lrwxrwxrwx 1 root root 10 Jul 22 12:30 25bddd6a-d210-486d-832e-087f2350859f -> ../../dm-3
lrwxrwxrwx 1 root root 10 Jul 22 12:30 4f989ec1-1c28-4c15-8953-de9f2dc549be -> ../../sdd1
lrwxrwxrwx 1 root root 10 Jul 22 12:30 6219e3d0-c754-44e7-a822-f9fb541f0c7f -> ../../dm-1
lrwxrwxrwx 1 root root  9 Jul 22 12:30 6b5f43c8-e1c1-4aa8-8b9e-ea70936bdfda -> ../../sde
lrwxrwxrwx 1 root root 10 Jul 22 12:30 B9D4-9936 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jul 22 12:30 d18039c6-9608-401a-863a-a7897b456493 -> ../../dm-5
lrwxrwxrwx 1 root root  9 Jul 22 12:30 dde3743b-c8fe-43d0-b631-5f344c517b10 -> ../../sdf
lrwxrwxrwx 1 root root 10 Jul 22 12:30 f28e5a8e-0029-4964-852e-107c865d3bb4 -> ../../dm-2

Can you see any way around that?

[clefebvre]

thanks @MikeB5027, Timeshift is an Xapp project now. We took over the maintenance a little while ago.

[clefebvre]

oh sorry, you meant upstream.. referring to /dev/disk/by-uuid.. sorry my bad.

[MikeB5027]

Thanks Clem, yes, I was referring to /dev/disk/uuid. The bug doesn't stop timeshift from working with my btrfs mirror destination, and it was present in LM20 and earlier, but it does make initial configuration difficult. Maybe my use case is unusual but, as a retired storage sysadmin, a btrfs mirror seems like a good place to store my snapshots.

[MikeB5027]

/dev/disk/by-uuid, I mean. I have never tried reverting to a snapshot, so I have no idea whether that would be affected. Mike

[clefebvre]

Ah thanks @MikeB5027, I was afraid this was a regression from our recent changes. I remembered @mtwebster said they'd only affect rsync and not at setup time but I wan't sure.

OK, this is not a release blocker then. We should still look into it, but I'll move it to timeshift in the meantime.

[matrix9180]

I have a similar problem to this. I initially set up Timeshift with a single-disk btrfs root partition with btrfs snapshots. I later added another drive and made it a raid-1. When opening timeshift it shows the correct disk space available, but after entering settings or the wizard I'm told I don't have enough disk space (same as screenshot above). Hope this can get some attention soon, as I'd really like to reconfigure how many snapshots I'm keeping.

[hitobashira]

raid0 :: timeshift: "not enough disk space" when destination is btrfs raid0. E: Not enough disk space (< 1000 MB) E: Select another device or free up some space timeshift_btrfs.txt

occur or not."not enough disk space"

btrfs (raid0) The total remaining capacity is more than 1TB. Each individual disk has a capacity of less than 1TB.

Sometimes it becomes unusable, but when I launch timeshift-gtk again, it works fine. Mystery is.Exit as it is and restart timeshift-gtk again, it will be cured. Not sure.

It is almost certain that If I specify the save storage device on the command line.

Anyway, it's a mystery.

However, saving from the terminal works.maybe. eg sudo timeshift --list ; sudo timeshift --create --comments "with nemo_action problem🌸🌸🌸🌸 $(users) | $(lsblk -fl | perl -alnE 'm(\s/$) && print "@F[3]| @F[0](@F[1])"' ) "

I have been repeating this for about 1 years. I've experienced this more than 30 times in the past month. The reproducibility is a mystery, but I think the case is very similar. So I commented for reference.