Announcement

**GreyGeek** · Jun 05, 2018, 12:49 PM

Allow me to add a description between the differences between a read-write snapshot and a read-only snapshot.

Assume you have opened a root Konsole and mounted the drive that contains your Btrfs <ROOT_FS> mounted to the /mnt directory:
mount /dev/sda1 /mnt
/mnt is now <ROOT_FS>

It will have at lease two subvolumes and, perhaps, although it is not necessary, a subdirectory in which to store snapshots, if you create it:
@
@home
snapshots

A snapshot made using
btrfs su snapshot -r /mnt/@ /mnt/snapshots/@-snapshot
creates a read-only snapshot of @ in the /mnt/snapshots directory. Keep in mind that this is your current, live, working system! @ is where all your utility commands reside. This snapshot doesn't change @, it merely makes a "copy" of it as Oshunluver described. (Clone is another Btrfs command and a different topic)

Read only snapshots cannot be moved (mv) from their parent directory because, for example, the ".." of /mnt/snapshots/@-snapshot is tied to that parent directory, /mnt/snapshots.

A snapshot made without using the "-r" switch is a read-write snapshot. It cannot be sent to a foreign pool by the send & receive commands, but it can be used as an immediate rollback target. And, it can be moved from its parent directory to another directory with the mv command.

So, if you want to move @-snapshot from your working Btrfs pool (<ROOT_FS> or /mnt) to a Btrfs pool on a destination pool not part of your working Btrfs pool, (i.e., on another drive or server which you previously mounted using, for example:
mount /dev/sdc1 /backup
you must use the Btrfs send & receive commands.
btrfs send /mnt/snapshots/@-snapshot | btrfs receive /backup

This means that @-snapshot copied (not moved) to the external destination pool will also be an ro snapshot. IF you used Send & receive to fetch a ro snapshot from an external pool it will be written back to your system pool as an ro snapshot.
btrfs send /backup/@-snapshot | btrfs receive /mnt/snapshots

Because it is still ro,
mv /mnt/snapshot/@-snapshot /mnt/@
would NOT work because of the ro status.

So, the ro status is removed by creating a rw snapshot from the ro snapshot by omitting the -r switch. First, move the currently active @ volume.
mv /mnt/@ /mnt/@temp

Even though renamed as @temp, the source of all the commands you continue to use becomes @temp.
Now, create the rw @ volume from the ro @-snapshot subvolume:
btrfs su snapshot /mnt/snapshots/@-snapshot /mnt/@

/mnt/@ is the rolled back rw volume but @temp is still being used to supply working utility binaries. If you were to delete @temp right now it would completely disconnect you from your root binaries. You could do nothing more with your system. All further commands would fail. IF you deleted @temp before you made a rw copy of @-snapshot to make @, even a reboot would not restore your system. No utilities would work, including btrfs commands. So be sure to keep @temp (or what ever you name it) until after you successfully reboot. To complete the rollback you have to umount /mnt and /backup, and exit root and exit the Konsole. Then reboot. On the next boot up fstab connects the rolled back @ volume to / and it takes over.

I've been using Btrfs for over three years and I have yet to have a need to create a rw snapshot except to convert an ro snapshot to a rw snapshot.

**oshunluvr** · Jun 05, 2018, 01:54 PM

One reason to make a RW snapshot is if it's purely for roll-back usage on a single distro system (i.e. not dual booting). That way you don't have to have bootable USB around.

Example;

Prior to updating a kernel, take a RW snapshot of @ as @save.
Run the update and reboot.
Kernel fails to boot - reboot again.
Stop grub prior to beginning boot.
Edit the grub menu entry changing @ to @save in the three places it's in the menu item.
Continue the boot.

You can now continue working. Before shutting down or rebooting again:

Delete the damaged subvolume @ and RW snapshot @save as @.

You are now back where you started. Your next reboot should go normally. If you used a RO snapshot, you would have to boot into another distro on your system or to a LiveUSB stick to recover back to bootable. Using a RW snapshot in this way gets your system back up a lot quicker. I can think of other reasons why a RW snapshot can be more useful, but this is the most useful reason. RO is only used for backup purposes in my world.

In any case, as GG pointed out - changing a snapshot from RO to RW or back again is as simple as taking a new snapshot. You just can't do it from grub.

**oshunluvr** · Jun 05, 2018, 02:03 PM

There's also a "property" command that can change the RO status of a subvolume;

sudo btrfs property -ts @save ro false

would change @save from RO to RW.

The options "-t" means "type" and the "s" means subvolume.

This will show you the current status:

sudo btrfs property get @save

**GreyGeek** · Jun 05, 2018, 03:18 PM

Wow! Wasn't aware of the btrfs property command!
Only three properties that are settable, but being able to change a ro snapshotto rw makes things simpler!

Code:

:~$[B] btrfs property list /home[/B]
ro                  Set/get read-only flag of subvolume.
compression         Set/get compression for a file or directory
:~$ [B]btrfs property list /[/B]
ro                  Set/get read-only flag of subvolume.
label               Set/get label of device.
compression         Set/get compression for a file or directory

I mentioned accidentally deleting the active @ volume because I did that goof. It wouldn't boot because @ was gone so I had to mount it using my LiveUSB and fix it from there.
Luckily, I had a persistent LiveUSB of Neon with Btrfs as the root file system, so repairing it was a snap.

**oldgeek** · Jun 06, 2018, 06:07 PM

I've just made my first two snapshots (@ and @home) and they worked, but after reading all these posts I'm aware I know next to nothing about btrfs. But you say it's worth learning and will simplify my digital life, so I'm trying to soak it all in, bit by bit. I feel the same way as when I bought my first computer--a Sinclair ZX-81--and after plugging it all into a TV and a tape recorder, I didn't know what to do with it except start typing in and hoping for the best. Eventually I could do a number of things, and even attempted to learn machine language. It didn't happen. But I guess some things just take a little getting used to.

**Qqmike** · Jun 06, 2018, 06:40 PM

oldgeek: But I guess some things just take a little getting used to.

You're to be commended for your good attitude and persistence! Having to learn a new philosophy and a command repertoire and various other nuances (like booting) just to maintain your filesystem. Not everyone would even think of tackling all this. oldgeek! Don't be too hard on yourself!

**SpecialEd** · Jun 08, 2018, 07:58 AM

So if one was to do a fresh install of say Kubuntu 18.04 on a new SSD, what is the recommended partitioning scheme?

**GreyGeek** · Jun 08, 2018, 10:39 AM

One partition, /dev/sda1, containing the entire disk drive, unless you want to suspend. Then two, /dev/sda1 with all but an amount of GB space equal to your RAM + 10%. Btrfs won't use it but some programs may. So, /dev/sda1 and /dev/sda2.

Giving Btrfs /dev/sda1 as "/" will create two volumes, @ and @home under <ROOT_FS>, where <ROOT_FS> is where ever you mount it, say
mount UUID=xxxxxxxxxxxxxxxxxxxxxx /mnt
Then, /mnt is <ROOT_FS> and @ & @home reside under it:
/mnt/@
/mnt/@home
It is there that I mkdir /mnt/snapshots as a storage location for snapshots in a Konsole:
sudo -i
mkdir /mnt/snapshots
btrfs su snapshot -r /mnt/@ /mnt/snapshots/@20180608
btrfs su snapshot -r /mnt/@home /mnt/snapshots/@home20180608
sync
umount /mnt
exit
exit
The directory snapshots does not show on either "/" or "/home" because it is not part of either subvolume. It is a directory under <ROOT_FS>, where ever that happens to be mounted, and is visible only when it is mounted. A very secure place for snapshots.

Using that scheme you can later, if you wish, shrink the Btrfs <ROOT_FS> to something less than all of sda1 in order to make room for another partition on which to install something else.

Apps like snapper create hidden subdirectories:
/.snapshots
/home/.snapshots (or, /home/<username>/.snapshots, I forget which).
That are accessible because they are under @ and @home, as mounted in fstab as / and /home.

**SpecialEd** · Jun 08, 2018, 11:28 AM

Do you create dva/sdb2 as a Swap partition or designate it as swap through Btrfs?

**GreyGeek** · Jun 08, 2018, 02:52 PM

Originally posted by SpecialEd View Post

Do you create dva/sdb2 as a Swap partition or designate it as swap through Btrfs?

My choice would be to designate /dev/sdb2 as a swap partition. (Not a swap file inside /) Btrfs doesn't use swap of any kind, but some apps may.

**SpecialEd** · Jun 08, 2018, 03:53 PM

Originally posted by GreyGeek View Post

My choice would be to designate /dev/sdb2 as a swap partition. (Not a swap file inside /) Btrfs doesn't use swap of any kind, but some apps may.

Thank you for your teaching.

Now that I have this Acer just about where I want it, I have ordered an SSD -- which was supposed to be delivered tomorrow, but now they say Monday-- so I get to start all over again, so-to-speak. It sure is nice having another fully functioning machine around for easing the bumps along the road. (and remembering all the programs one has added).

**GreyGeek** · Jun 08, 2018, 06:43 PM

I have no experience with ssd's, but Oshunluver has. There are some setting that Btrfs makes automatically when it senses an ssd drive:
https://www.thegeekdiary.com/how-to-...r-performance/
but Oshunluver is the guy to consult if you have problems with Btrfs and your ssd drive.

While you can add an ssd drive to your existing HD Btrfs pool very easily, I suspect that mixing ssd's with HD's wouldn't be a wise thing to do.

**oshunluvr** · Jun 09, 2018, 10:26 AM

Hey Ed,

GG's got it right with only two other considerations: EFI and GPT.

If you are planning on using a GPT partition table, you need the reserve a small partition for grub. Here's the How-To for that. This is no biggie as it uses space otherwise wasted on the disk if you do it my way.

The other is EFI, if you're using it you will need a small EFI partition (about 500MB). Worth considering is if you're using EFI you can use other boot managers rather than grub. Here's some info on all that.

So assuming Legacy boot (non-EFI) and using GPT partition table (I recommend it), and swap to hibernate too, you would need 3 partitions, 4 if you're using EFI.

As far as "mixing" HD and SSD on the same btrfs file system, I wouldn't recommend it for a couple reasons;
1) Because btrfs detects SSDs and adjust to them. I don't know what it would do if you mixed one with a HD, but I wouldn't do it without some research and testing.
2) You'd likely slow down the access to the SSD so much because you be sharing access time with the HD that you'd lose much of the benfefit of the SSD.

A better and safer course would be to have two btrfs file systems - one on each device - and use them separately, which you easily do by mounting subvolumes as needed. Plus then you can backup subvolumes from one device to the other and have a solid backup if one device fails.

**oshunluvr** · Jun 09, 2018, 10:31 AM

Here's the current mount options I'm using:

btrfs rw,noatime,nodiratime,space_cache,compress=lzo,aut odefrag,subvol=@ 0 0

The SSD optimizations are enable by default. Trim should be run as a cronjob and not as an fstab option.

Wow, weird. I cannot make the space go away in "autodefrag" above.

Announcement

BTRFS subvolumes and the space they occupy explained

BTRFS subvolumes and the space they occupy explained

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment