Merging root partition into another...

[GreyGeek]

oshunluvr, I'll see your 72GB and raise you 104GB !!


chconnor, The BTRFS usage command shows that I have used 176GB on my 500GB SSD main drive.
I have an internal 1TB drive on which I store my archived BTRFS fs. I have stored 23 subvolumes of my system (which has just one subvolume: @rootfs) That's supposedly over 4TB on a 1TB SSD and I've used only 236GB of the 1TB drive! Part of it is due to the automatic compression that BTRFS has, if you use it. The automatic compression makes no detectable difference in the speed of operation of my system.

mount /dev/nvme0n1p1 /backup/

root@GreyGeek:~# vdir /backup/
total 0
drwxr-xr-x 1 root root 352 Aug 4 21:40 @202308042139
drwxr-xr-x 1 root root 352 Aug 5 19:38 @202308051937
drwxr-xr-x 1 root root 352 Aug 6 22:13 @202308062210
drwxr-xr-x 1 root root 352 Aug 7 20:22 @202308072021
drwxr-xr-x 1 root root 352 Aug 8 21:47 @202308082146
drwxr-xr-x 1 root root 352 Aug 9 20:12 @202308092010
drwxr-xr-x 1 root root 352 Aug 10 19:04 @202308101859
drwxr-xr-x 1 root root 352 Aug 11 16:18 @202308111617
drwxr-xr-x 1 root root 352 Aug 12 20:20 @202308122019
drwxr-xr-x 1 root root 386 Aug 13 20:01 @202308132000
drwxr-xr-x 1 root root 390 Aug 14 21:04 @202308142103
drwxr-xr-x 1 root root 390 Aug 15 21:52 @202308152151
drwxr-xr-x 1 root root 390 Aug 16 19:09 @202308161908
drwxr-xr-x 1 root root 390 Aug 17 20:00 @202308171959
drwxr-xr-x 1 root root 402 Aug 18 21:33 @202308182132
drwxr-xr-x 1 root root 402 Aug 19 15:53 @202308191552
drwxr-xr-x 1 root root 402 Aug 20 22:30 @202308202229
drwxr-xr-x 1 root root 402 Aug 21 19:51 @202308211950
drwxr-xr-x 1 root root 402 Aug 22 20:57 @202308222056
drwxr-xr-x 1 root root 402 Aug 23 21:36 @202308232135
drwxr-xr-x 1 root root 402 Aug 24 20:57 @202308242056
drwxr-xr-x 1 root root 402 Aug 25 21:16 @202308252115
drwxr-xr-x 1 root root 402 Aug 26 21:52 @202308262150

root@GreyGeek:~# btrfs fi usage /backup/
Overall:
Device size: 931.51GiB
Device allocated: 345.04GiB
Device unallocated: 586.47GiB
Device missing: 0.00B
Device slack: 0.00B
Used: 236.17GiB
Free (estimated): 692.73GiB (min: 692.73GiB)
Free (statfs, df): 692.73GiB
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 453.12MiB (used: 0.00B)
Multiple profiles: no

Data,single: Size:338.01GiB, Used:231.75GiB (68.56%)
/dev/nvme0n1p1 338.01GiB

Metadata,single: Size:7.00GiB, Used:4.41GiB (63.06%)
/dev/nvme0n1p1 7.00GiB

System,single: Size:32.00MiB, Used:64.00KiB (0.20%)
/dev/nvme0n1p1 32.00MiB

Unallocated:
/dev/nvme0n1p1 586.47GiB[/code][code]


Read @oshunluver's BTRFS documents and you'll never regret it.

[chconnor]

Thanks -- we're talking about the various docs here, right? https://www.kubuntuforums.net/forum/...llaneous/btrfs

[GreyGeek]

Thanks -- we're talking about the various docs here, right? https://www.kubuntuforums.net/forum/...llaneous/btrfs

That's the subforum!
Just a couple of comments...
Ubuntu based systems install two subvolumes when BTRFS is used as the fs. @ (rootfs) and @home, mounted as "/" and "/home". I got tired of saving two snapshots to backup my system and having to rollback two snapshots when I wanted to revert a change or recover from one of my many experiments.

What I did was run a LiveUSB and mount my BTRFS drive to /mnt (for most BTRFS operations you can run your system while having it mounted to /mnt, but not if you are going to delete @home) and then copied the contents of @home (which contained my account subdirectory) to @root/home. Then I edited /etc/fstab on the drive (not the LiveUSB) and commented out the line that mounted @home to /home. After rebooting I used "btrfs su delete -C /mnt/@home" to free up the @home subvol and return it to the btrfs pool.

oshunluvr did a similar thing but in a different way. It's described in that subforum.

BTRFS automatically tunes itself so there are very few "parameters" to adjust. I only use one occasionally, which changes a snapshot from r to rw or from rw to r. I don't remember any other adjustable parameters, which shows how much they are needed in 5+ years of usage.

A LOT of people use TimeShift to create backup snapshots of their BTRFS system. I tried it and didn't like it. One word of caution -- if you do use TimeShift and later decide to uninstall it BE SURE to use it to delete all the subvolumes it created BEFORE you uninstall it.

Another archival tool for BTRFS is snapper. It creates a storage volume for @ under /.snapshots and for @home under /home/.snapshots. Since you can't move a subvolume inside another subvolume (except for rootfs) you'll notice that snapper's snapshots has a file structure of
/.snapshots/1/@snapshot,
/.snapshots/2/@snapshot
... where the numbers are normal file directories.

My personal preference was for snapper but after a while I decided to write my own scripts to make snapshots when and in my own way.

Taking a snapshot is about instantaneous and does not use much disk space. However, eventually it will fill up as your file system makes changes. The BTRFS devs recommend a maximum of 10-12 snapshots per subvolume. All of this is explained in the BTRFS subforum.

[chconnor]

Thanks for the tips!

[jlittle]

...the BTRFS devs recommend a maximum of 10-12 snapshots per subvolume.

I don't understand that. I often have a few hundred. Still, that sparked me to do a clean up on this computer, and now I'm under 100 for root, home, and work drive.

[GreyGeek]

I don't understand that. I often have a few hundred. Still, that sparked me to do a clean up on this computer, and now I'm under 100 for root, home, and work drive.

https://packages.debian.org/search?k...ll&section=all

While segmenting datasets using subvolumes will usually speed up operations that require walking the backref tree, creating too many snapshots has the opposite effect. Too many snapshots, (NOTE: check check snapper snapshot retention policy) will cause performance crashes somewhere between 12 snapshots per subvolume and/or 100 subvolumes per volume—including all snapshots. (btrfs.wiki.kernel.org, Having many subvolumes can be very slow) An obscene number of snapshots can also sometimes wedge the volume into an unmountable state.

I wrote that section after reading this email from the BTRFS developers: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg72416.html

[jlittle]

Thank you for that reference. I'm somewhat reassured...

...the scaling issues primarily affect btrfs maintenance commands themselves, balance, check, subvolume delete....
...for home and SOHO type usage... a max of 100 or so snapshots per subvolume is ... a strong recommendation...

Subvolume delete is the only command I use often, like my clean up yesterday. This laptop's main storage is now well under 100 snapshots per subvolume, so I think I'm ok. The previous mess was the result of moving stuff around (banishing Windows from the smallish NVMe).

[Snowhog]

For strictly home use, I’ve never understood the need for so many backups/snapshots. Making one before a major change/upgrade makes perfect sense, but more than that…

[jlittle]

For strictly home use, I’ve never understood the need for so many backups/snapshots…

What is your defence against an erroneous rm and the like? An inadvertent ctrl-A del ctrl-S? Detected some time later, perhaps the next day? Even diagnosing what has happened when work has disappeared can be difficult.