Announcement

**oshunluvr** · Aug 20, 2015, 11:06 AM

I've only had one "DD" since installing 15.04 but the fix only required a new user folder, not a re-install. My issue revolved around mis-configuring multiple monitors eventually borking my user settings to an irreparable state.

I use 15.05 daily but I'm also not mucking about with themes and the like. It reminds me of when we transitioned from KDE3 to KDE4. I did install a VM of 15.10 and played a bit. It looks pretty solid for beta. I will probably install it to bare metal soon.

BTW, I know you didn't post looking for solutions, but I have a suggestion if you're up for it:

For your next install, install to a BTRFS partition. Why? In a word: Snapshots. A few characters in a terminal and you have a rollback point. No re-install required. Snapshots are pictures in time of a subvolume. When needed, you can delete the original subvolume and boot the snapshot or delete a snapshot. Here's the scenario:

Do a new install. Make a snapshot.
Do a full upgrade. Make a snapshot.
Upgrade went OK? Great! Delete first snapshot.
Yadda, yadda, yadda, add some themes and new stuff. Make a snapshot.
New stuff and themes OK? Delete previous snapshot.
WAIT: Theme broke your install? Elevate last snapshot to bootable level and delete the previous bootable subvolume.
Continue as long as desired.

There are some GUI tools for some of this, but I prefer the terminal for system work at this level.

By way of basic explanation; A BTRFS filesystem contains subvolumes (should be used this way, but subvolumes are a feature, not a requirement). Each subvolume is separate from the others but they all exist within the same filesystem. Bonus: All your free space is available to all your subvolumes when/if needed - no wasted partitioned space! A snapshot is a "copy" of a subvolume and is a subvolume all onto itself. A snapshot doesn't take up any space when made. It fills up as you make changes to the original subvolume (source subvolume). Any subvolume can be booted (if it contains an install, obviously) so you can boot to a snapshot and return to the previous state of your install. You would also be able to make snapshots of your home subvolume. Read-only snapshots can even be "sent" to other drives even over a network for backup purposes and can be done incrementally (only changes copied) - a great way to backup your home.

The default (K)Ubuntu install uses a separate home subvolume thus your home is easily backed up and protected from a re-install. You've been around long enough that all of this would be easy enough. Read up a bit (I've posted all over this forum about btrfs and it's wonders

) and try it out. You'll never look back.

ADDED: BTW, I currently have three installs on a single btrfs filesystem. I simply change the default subvolume names Ubiquity uses after each install and then install a new version right along side.

**Spadge** · Aug 20, 2015, 02:20 PM

Originally posted by oshunluvr View Post

BTW, I know you didn't post looking for solutions, but I have a suggestion if you're up for it:

I wouldn't have posted at all if I were against discussion though.

Thanks for the post, I will read and digest it.

I only have a small Linux boot disk (SSD) so snapshots may not be an option. I've always favoured flat filesystems, so don't have a separate ~ slice.

BTRFS sounds pretty awesome though. Worth bearing in mind for if not this time then next time.

**GreyGeek** · Aug 20, 2015, 02:21 PM

I second oshunluvr's suggestion about btrfs.

You can mount your active btrfs:

Code:

$ sudo fdisk -l
[sudo] password for jerry: 


Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0000b9ae


   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048  1230731263   615364608   83  Linux
/dev/sda2      1230731264  1250263039     9765888   82  Linux swap / Solaris
jerry@jerry-Aspire-7739:~$ sudo mount /dev/sda1 /mnt
jerry@jerry-Aspire-7739:~$ vdir /mnt
total 0
drwxr-xr-x 1 root root 196 Aug 19 20:29 @
drwxr-xr-x 1 root root  66 Aug 19 21:09 @home
jerry@jerry-Aspire-7739:~$ sudo umount /mnt
jerry@jerry-Aspire-7739:~$

While mounted you could create snapshots (@_backup, @home_backup) of both @ and @home, which are mounted in fstab as / and /home. Each is given a UUID which could be used in fstab to change the mount points.

Or, you could use snapper, which allows you to create snapshots automatically as pre and post when you fire up muon. Or, you can write a script to do it exactly the way you want to:
snap_pre_post.sh

Code:

#!/bin/bash
# created by Jerry L Kreps on July 20, 2015 and released under the GPL 2.0.
# This script merely creates a snapshot in both root and home with the designation of PRE or POST as the type, 
# which indicates that the user created it before an action or afterwards.
# This script is run with PRE as the TYPE before an action which you may want to reverse
# AND this script run again with POST as the TYPE after that action has been completed.  Both snapshots are singletons because
# no timeline is used.  Only the "PRE" or"POST" in the description, along with a timestamp, links the pre to the post snapshot.
# To reverse the action run the following two snapper commands:
#
# snapper -c home udochange n..m   where n or o is the number of the PRE and m or p is the number of the POST snapshot
# sudo snapper -c root undochange o..p
#
# After running those two commands both of the empty snapshots folders can be deleted using
#
# snapper -c home delete n-m
# sudo snapper -c root delete o-p
#
#
#
NOW=$(date +%Y%m%d%H%M)
echo Enter snapshot type PRE or POST:
read TYPE
echo Enter description
read DESC
STR=$TYPE" "$DESC" "$NOW
echo $STR
HCMD='snapper -c home create -d "'${STR}'"'
RCMD='sudo snapper -c root create -d "'${STR}'"'
eval "$HCMD"
eval "$RCMD"

I have turned off the timeline and automatic snapper settings because I want to make snapshots only when I want to make them.

The good snapper is 0.2.6-0 (snapper_0.2.6-0_amd64.deb) and includes several files, one of which (has zypp in its name) is not needed.

**oshunluvr** · Aug 20, 2015, 02:42 PM

Originally posted by Spadge View Post

I wouldn't have posted at all if I were against discussion though.

Thanks for the post, I will read and digest it.

I only have a small Linux boot disk (SSD) so snapshots may not be an option. I've always favoured flat filesystems, so don't have a separate ~ slice.

BTRFS sounds pretty awesome though. Worth bearing in mind for if not this time then next time.

Actually, one of the great things about btrfs is the snapshots take no room at all and happen instantaneously. Example: Your install is 6GB. You snapshot prior to an update. The snapshot takes zero data space (only metadata space) at this point. The you do the update and the update replaces 500MB worth of data. Your snapshot grows to 500MB. So now total space taken is 6.5GB. Once you determine the update went OK, you can delete the snapshot and free up the space - right back to 6GB. The snapshot will continue to grow as files are replaced or amended - filling up with the older versions of the files - until you delete it.

In my example above, your install subvolume would contain all the original installed files (6GB) and the updated (500MB) files minus what was removed by the update (500MB) for a size of 6GB. The snapshot subvolume would contain all the original installed files (6GB) and NONE of the updated files. A file listing would report 12GB of files but actually only 6.5GB is in use. Any files that weren't updated after the snapshot would be listed in both subvolumes. Interestingly, you could boot to or mount and access either subvolume and have a live look at pre- and post-update conditions. Neat, right?

The other real beauty of btrfs with small disks is no partitions required and all free space smashed together all the time and available to any subvolume. On a 32GB SSD you might partition into 3 partitions - install 1 at 10GB, install 2 at 10GB, home at 12GB. With btrfs, leave it all on the same file system by using subvolumes so you'd have a single 32GB partition and all free space would be available to expand either install or your home - all transparent to you - no re-sizing partitions or wasted space ever again.

**oshunluvr** · Aug 20, 2015, 03:03 PM

Since others might read and be interested: The default subvolume naming convention used by *Buntus is to begin the name with a @ to differentiate it from a regular folder. Ubiquity (the Kubuntu installer) uses "@" for root install and "@home". If you look for a post by me regarding multi-booting to btrfs, you see how I rename this default into something more meaningful. Here's what my main boot drives look like:

Code:

drwxr-xr-x 1 root   root   382 May 28 12:21 @Kubuntu_14_04
drwxr-xr-x 1 root   root    48 Jan 25  2015 @Kubuntu_14_04_home
drwxr-xr-x 1 root   root    48 Jan 25  2015 @Kubuntu_14_04_home_ro
drwxr-xr-x 1 root   root   382 Apr  8 14:16 @Kubuntu_14_04_ro
drwxr-xr-x 1 root   root   284 Aug 19 09:03 @Kubuntu_15_04
drwxr-xr-x 1 stuart stuart  86 Jul 27 09:51 @Kubuntu_15_04_home
drwxr-x--- 1 stuart stuart   0 Feb 21 07:14 @stuart

14.04 and 15.04 each have their own home and my personal (docs, etc.) files are under @stuart. The two 14.04s you see with "_ro" at the end are read-only snapshots that I made to send a backup to another drive that I haven't deleted yet. To my comments from the previous post about free space: This is a two disk btrfs filesystem (2x256GB SSDs). When mounted, all the subvolumes show the same amount of free space - 460GB. To get the listing above showing all the subvolumes together, I mounted the primary volume /dev/sdi3. To mount a btrfs subvolume by itself, I mount /dev/sdi3 with the "subvol=" option.

**GreyGeek** · Aug 20, 2015, 08:43 PM

The snapper script I posted above doesn't use KDialog, just bash commands. I began writing a version using KDialog which ran fine but cluttered the output with ibus error messages. I didn't have iBus installed. So, I ran snapper_pre_post.sh before I installed iBus, using "PRE" as the type, and after I installed iBus, using "POST" as the type, along with a short description. Here is what snapper shows:

Code:

$ snapper -c home list
Type   | # | Pre # | Date                            | User  | Cleanup | Description                                  | Userdata
-------+---+-------+---------------------------------+-------+---------+----------------------------------------------+---------
single | 0 |       |                                 | root  |         | current                                      |         
single | 1 |       | Thu 20 Aug 2015 09:24:21 PM CDT | jerry |         | PRE Prelude to installing ibus 201508202124  |         
single | 2 |       | Thu 20 Aug 2015 09:33:19 PM CDT | jerry |         | POST After installation of iBus 201508202133 |        
 
jerry@jerry-Aspire-7739:~$ sudo snapper -c root list
Type   | # | Pre # | Date                            | User | Cleanup | Description                                  | Userdata
-------+---+-------+---------------------------------+------+---------+----------------------------------------------+---------
single | 0 |       |                                 | root |         | current                                      |         
single | 1 |       | Thu 20 Aug 2015 09:24:27 PM CDT | root |         | PRE Prelude to installing ibus 201508202124  |         
single | 2 |       | Thu 20 Aug 2015 09:33:26 PM CDT | root |         | POST After installation of iBus 201508202133 |         
jerry@jerry-Aspire-7739:~$

If iBus messes up my system all I have to do is issue the commands:
snapper -c home undochange 1..2
sudo snapper -c root undochange 1..2
and I am back where I was before I installed iBus.

**oshunluvr** · Aug 21, 2015, 06:02 AM

That's very slick Jerry.

I think a lot more users would embrace btrfs if we had a few nice tools like that built into the menu system.

**Spadge** · Aug 21, 2015, 06:32 AM

What's the downside of using Btrfs instead of one of the EXTs?

All I can make out from reading stuff is that "It's a little bit slower than EXT4 or XFS" - is that enough of a reason to not just make it the default filesystem for our 'buntu?

I'm no stranger to snapshotting (I used UFS in FreeBSD for years), but only ever used the snapshot for doing tape backups.

**oshunluvr** · Aug 21, 2015, 08:15 AM

The speed differences are unnoticeable in real world use IME. A lot of that info is old. If you set your mounting options correctly, you'll be as fast (or nearly so) as any EXT4 file system. In my world, even if it was 10% slower, the ease of use and extra features would still make it the better choice. Plus, if you have multiple devices you can create RAID filesystems with a single command, decreasing your access times.

As far as not being the default yet: I think it's mostly that it's under heavy development (the file system format is stable, just the tools are being developed) and the lack of a wide variety of data recovery tools. They've added a couple new ones as of last month, but they're not yet in the main release. There is a fsck function now but frankly, backups are the only insurance that works anyway. I think it's foolish to rely on recovery tools for data security. I've had a single corruption event caused by a faulty drive controller. Six files were damaged (I was able to determine exactly which files were using the bad inode) so I was easily able to replace them. I'd be surprised if btrfs wasn't the default in a year or two.

The developer of EXT4 openly acknowledges that it's a stop-gap format until we have something better. Now that IBM is in the Open Source Linux game, we may see more rapid development of btrfs and/or the addition of ZFS into the mainline kernel.

The one thing that btrfs cannot do at this point is swap files or dynamically expanding virtual disks (like VBox might use). The solution is to use a swap partition (like most of us do anyway) instead of a swap file and use fixed-size virtual disks or have a separate EXT4 partition for dynamic disks. My PC has 2 SSDs and 2 large HDDs at the moment so there's plenty of room here for the latter option

**Spadge** · Aug 21, 2015, 09:49 AM

Originally posted by oshunluvr View Post

The one thing that btrfs cannot do at this point is swap files or dynamically expanding virtual disks (like VBox might use). The solution is to use a swap partition (like most of us do anyway) instead of a swap file and use fixed-size virtual disks or have a separate EXT4 partition for dynamic disks. My PC has 2 SSDs and 2 large HDDs at the moment so there's plenty of room here for the latter option

I have 16 gig of RAM and a 120 gig SSD to boot off; what would I possibly use a Swap for?

**Spadge** · Aug 21, 2015, 09:52 AM

Originally posted by oshunluvr View Post

For your next install, install to a BTRFS partition.

I'm sold. Next install (15.10 hopefully) I'm cleaning out the closet and will go over to Btrfs.

**oshunluvr** · Aug 21, 2015, 10:16 AM

Great. Message back once you get into it and let us know how it goes.

I use space_cache and compress=lzo mount options. relatime is default now, but noatime can be a bit faster. I leave mine at relatime.

**GreyGeek** · Aug 21, 2015, 10:59 AM

I used to use EXT4 on previous Kubuntu releases but chose btrfs when I installed 14.04 a year and a half ago. Speed wise I cannot tell any difference. I have Debian JessieKDE and ArcherKDE running as guest OS in VBox with 30GB fixed sized virtual drives.and they both run great at full screen.

As guest OS's I've tried several distros with different btrfs structures than Kubuntu's. One had subvolumes for all the major mount points, /, /boot, /home, /var, /bin, /usr, etc.... It was a pain to work with. One had just / (@) as a mount point. You can't snapshot a regular directory and that made snapshotting a pain. Kubuntu is just right. Got to go, setting a sick grandkid.

**jlittle** · Aug 21, 2015, 04:06 PM

Originally posted by oshunluvr View Post

... Now that IBM is in the Open Source Linux game, we may see more rapid development of btrfs...

I don't understand that comment. IBM has been a major supporter of Linux (as measured, say, by code commits) for a long time, at least a decade IIRC.

Regards, John Little

Announcement

Desktop Death

Desktop Death

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment