Proposal for a improved software distribution using BTRFS

[SteveRiley]

your averageJosé
an average Джо
say Józef

Nice

Does his backups with snapshots (takes less than a second)

A snapshot is not a backup -- what happens when the pointed-to data ceases, for some calamitous reason, to exist?

[oshunluvr]

To continue jacking the thread, how stable is btrfs these days, in terms of potential data loss, etc? Is it a feasible alternative for average Joe users with average Joe systems, or is it more for professional or industrial use¿

I would say the average Joe can use it. At it's base level, it no harder to use than EXT4 is. The really advanced features require terminal use (no GUIs yet) but if your averageJosé takes the time to read a bit (Arch and Gentoo both have detailed wiki's on btrfs) he could even use those features.

The hardest part is the install. Most distros don't support brfs installation. Luckily, the *buntus do. They even use separate subvolumes by default; installing the OS to @ and the home to @home. If you read my post on the forum I explain how to change the default install to a specific subvolume name (I use @Kubuntu_15_04 fro example). That way I can do side-by-side installs to the same pool (btrfs filesystem). You can even convert an existing EXT4 partition to btrfs - unmounted of course. That's one of the few things you have to be unmounted to do, just about everything else except fsck can be done while mounted.

As far as stability, dibl and myself have been using btrfs since 10.10 or so when it was introduced. AFAIK, neither of us have lost any data. Not to say it couldn't happen, but it hasn't. If you read the 'net a bit you will see warnings about the fsck tool not yet being mature. I've had a couple errors (I refer above to CRC issues) caused by a hardware problem (my sata controller has been dropping off for a few milliseconds every so often) so you can't blame the filesystem for that. Fortunately, they are working hard to make btrfs a one-stop solution. Along with backup and rollback and the other features I listed above, it has built in data recovery (last resort stuff) and they fsck tools are in heavy development mode. The filesystem itself is static (no format changes down the road) and every kernel update brings more speed and function.

I see a couple real-world best use cases for btrfs and an average Джо:

A single small SSD: The need for a partitioning goes away when you use btrfs. Simply create and delete subvolumes at will and mount them as though they were partitions. The real advantage here is all the free space is part of the pool so your root, home, data, spare, backup, whatever "partitions" now share the free space and take it when they grow. No advance guessing how many gig's will be need for root, etc. If you have a 2TB drive, who cares if you waste a dozen GBs or even more? You don't even notice. But with a 64GB ssd, you might regret partitioning 20GB for your install only to find yourself using only 8GB of it. He makes his on-line backups with snapshots and off-line backups (btrfs send/receive) to a USB drive to the cloud or over his network to a server.

Several large HDDs: Managing large volumes of space can be time consuming and daunting. Let's say Józef has 3x1TB drives and wants to protect himself against drive failure (redundancy) and also have good regular backups. With btrfs you have choices and flexibility (you can change your mind). He wants some speed so he configures his entire 3TB as a single filesystem (minus a swap partition or three - btrfs can't do swap yet) in RAID0. 2.7TBs (or so), Nice! Does his backups with snapshots (takes less than a second) via a script and a cron job. He's all set. But wait - one day he realizes if a drive fails (thrice as likely if you have three) he's porked. So he removes one drive from the pool - he does this while using his computer, no unmounting necessary. Now he has a RAID0 2 drive filesystem of about 1.8GB and a single 900MB drive. Then he converts the RAID0 pool to RAID1 - again while "live". Now he has a 900MB main RAID1 filesystem (redundancy) and a second 900MB file system. RAID10 requires 4 devices, so he rewrites the script and uses the stand-alone filesystem as backup space. IMO, way easier than LVM or MDADM RAID.

Cool right? Other possibilities are endless. RAID10 with 4 devices means you could do it with three drives - just partition them into 6 equal sized partitions and use 4 of them as RAID10 (although you lose some of the advantages of RAID10 doing this). Have drives of different sizes? Partitions are devices so I had my server with 2x1TB drives and 2x2TB drives as six 1TB partitions, four of them in RAID10 and the other two in RAID0. You can do all this with MDADM or LVM but it's much more time consuming to build and once built - you're pretty much committed.

[dibl]

To continue jacking the thread, how stable is btrfs these days, in terms of potential data loss, etc?

Clay, my anecdotal evidence is, with 3 or 4 power failures over these years while my system was running, there was no hint of a problem on the btrfs filesystem.

As far as the level of technical challenge, if you can issue

mkfs.btrfs /dev/sdb /dev/sdc

then you can make a btrfs filesystem across two hard drives, with striped data and mirrored metadata. That's how hard it is.

https://btrfs.wiki.kernel.org/index....ltiple_Devices

[vinnywright]

all my data is on a TB-drive formatted btrfs . it gets mounted at boot with a line in fstab

        [FONT=monospace][COLOR=#000000]#storage drive [/COLOR]
/dev/sdb1 /mnt/disk    btrfs     rw,relatime,space_cache,compress=lzo     0    0

[/FONT]

as /mnt/disk

        [FONT=monospace][COLOR=#000000]vinny@vinny-Bonobo-Extreme:/mnt/disk$ ls [/COLOR]
[COLOR=#5454ff][B]@ [/B][/COLOR][COLOR=#5454ff][B]@data [/B][/COLOR][COLOR=#5454ff][B]@home[/B][/COLOR][COLOR=#5454ff][B] kubuntu [/B][/COLOR][COLOR=#5454ff][B]@snap[/B][/COLOR]

[/FONT]

I have a directory /Kubuntu on it that contains

        [FONT=monospace][COLOR=#000000]vinny@vinny-Bonobo-Extreme:/mnt/disk/kubuntu$ ls [/COLOR]
[COLOR=#5454ff][B]Documents[/B][/COLOR][COLOR=#5454ff][B] Downloads [/B][/COLOR][COLOR=#5454ff][B]dwhelper [/B][/COLOR][COLOR=#5454ff][B]Music [/B][/COLOR][COLOR=#5454ff][B]MyMachines[/B][/COLOR][COLOR=#5454ff][B] Pictures [/B][/COLOR][COLOR=#5454ff][B]steam[/B][/COLOR][COLOR=#5454ff][B] Videos[/B][/COLOR]

[/FONT]

these get used in all my installs for that installs ~/ directory’s ,,,,,this drive with the kubuntu directory started life as ext4 and was converted with the data in place ,,,,,,,,,the adventure is @hear https://www.kubuntuforums.net/showth...-data-to-btrfs

it now has a OS install on it as well as my data ,,,as you could probebly tell from the @'s ,,,,,,,I have had no trouble with it as yet

VINNY

[SteveRiley]

To continue jacking the thread, how stable is btrfs these days, in terms of potential data loss, etc? Is it a feasible alternative for average Joe users with average Joe systems, or is it more for professional or industrial use¿

I started with Btrfs on my machines in the 14.04 cycle. Never ran into a problem with daily use on two laptops. Oshun and Dibl have been running it even longer and would also report similar stellar results. While I see reports elsewhere of people having major problems, I'm not exactly sure what their problems are. I've even forced some crazy situations on my non-production laptop like instant power outages during writes and was simply not able to fsck up the file system

[claydoh]

To continue jacking the thread, how stable is btrfs these days, in terms of potential data loss, etc? Is it a feasible alternative for average Joe users with average Joe systems, or is it more for professional or industrial use¿

[Feathers McGraw]

That was a great explanation, thank you

[oshunluvr]

Neat!

One thing I'm curious about is how it seems relatively difficult to make a read-only snapshot read-write. I take it there's something clever going on there - why do you have to create an entirely new snapshot? I would have expected it to be some kind of flag that you change without changing the actual data?

AFAIK, you can't change the R/O flag to R/W, but it takes longer to type the snapshot command than to make a new snapshot:

sudo btrfs subvolume snapshot -r <source> <dest>

makes a read-only snap

sudo btrfs subvolume snapshot <source> <dest>

makes a R/W snap. Happens instantly. Now simply delete the R/O version and you are done. The reason for using the R/O snap is only to send it to another drive. The filesystem is mounted, therefore assumed in use, so a dynamic snapshot (R/W) may change during the send process and corrupt itself (actually, causes the receive command to fail). You would not want an R/O snap if you were using it for rollback because you'd have the needlessly make a new copy before mounting it and putting it to use.

Understand that a snapshot isn't a copy of any data, rather it's a second set of file handles to the data that already exists. Initially, the snapshot takes NO drive data storage space (meta data space only). The snapshot grows in size as it ages and the original (source) subvolume changes. Files that are changed after the snapshot are actually left intact and the source subvolume releases it's handle (probably not the correct term) but the snapshot retains the handle. In this way the changed file exists both in it's original state and it's changed state - but now in two different subvolumes - the source and the snapshot.

Example: Prior to a package update; take a snapshot. Free space doesn't change. Do package update. Free space reduces by size of update (nothing actually deleted). Snapshot now is using space. Delete snapshot. Free space returned to pool (original files deleted).

The real fun begins when you have a series of snapshots. A file moves down the chain until the final snapshot that records it's existence is deleted. I know, I know - I have a low tolerance for fun...

[dibl]

IIRC, the newer fdisk dropped the capability to specify heads (-H) and sectors (-S), in favor of some safe default values for the new parameter "sectorsize". So if you really, for some unusual reason, want to control the cylinder number and size you'll need a bootable device with an older Linux OS and the older util-linux package.

Back to btrfs. I have not done nearly as extensive experimentation with it as oshunluvr and greygeek did. What I was looking for was serious security for my data -- the kind you get with a $500 RAID controller and set of 3 or 4 hdds. How nice it was to find that FOSS offers an open-source solution in software and all I needed to do was buy a pair of large hdds and install the filesystem directly on the devices. Five or six years later, on my system that runs 24/7/365, I have replaced the drive set once with very little drama, and not lost a byte of data out of 700GB. I let the OS run on a fast PCI-bus SSD, on an ext4 filesystem, and that remains the same, with normal updates, as when I installed it in NOV of 2010. I'm not afraid of losing my OS as it would be relatively quick and easy to replace, but my data are another story.

[SteveRiley]

Yeah, big diif from 14.04 to 15.04:

I think the newer fdisk appeared in util-linux 2.25, so anyone with 14.10 or higher should have it.

[Feathers McGraw]

Neat!

One thing I'm curious about is how it seems relatively difficult to make a read-only snapshot read-write. I take it there's something clever going on there - why do you have to create an entirely new snapshot? I would have expected it to be some kind of flag that you change without changing the actual data?

[oshunluvr]

Don't, I'm actually quite fond of thread jacking. I was expecting the discussion to teach me some interesting things about BTRFS too.

dibl, greygeek and myself have posted quite a few threads on here on btrfs. I'm still playing around with it quite a bit. The backup/rollback thing is ripe for automation, but I haven't taken the time to do it yet. There is/was a btrfs auto-backup in the repos awhile back, but GG's testing proved it unusable. Here's a run down of what I'd like it to do automagically:

Rollback:
Auto-snapshot prior to package install/update.
Delete auto-snapshots at a configurable number or age.
Restore the rollback snapshot when requested.

Backup:
Incremental auto-backup at a configurable interval.
Restore backup on request.

The fun thing I'm playing with lately is the send/receive feature. You can send a subvolume to a different device or to a file for backup purposes. I have 2x256GB ssd's as my primary btrfs filesystem and a 2TB hdd with a 1.6TB btrfs filesystem as my backup/storage device. I can send a read-only snapshot of any of my 10 subvolumes to the backup device, but it's a little cumbersome:

1. Make R/O snapshot
2. Send/Receive snapshot
3. Delete R/O snapshot

Restoring/rolling back is even more so:

1. Send/Receive R/O snapshot (reverse direction).
2. Make new R/W snapshot of received backup snapshot.
3. Delete R/O snapshot.
4. Unmount old subvolume.
5. Rename subvolumes (to avoid fstab edits).
6. Mount restored subvolume.
7. Delete unneeded subvolume.

But it is super cool to be able to do a full backup while still using the system and without any real configuration. I've never liked any of the backup utilities I've seen, preferring rdiff-backup in a cron job instead. If you desire redundancy protection, it's super simple to use RAID1 on two devices, so that's a no-brainer. Once I get a chance to spend some time, I might write a script to do all this. Maybe also having it send update messages to the notifier during operation.

One issue I'm having right now is due to a hardware problem (flakey sata controller - old machine) caused some CRC errors on my 14.04 install. Easy enough to figure out which files were damaged - inodes with bad CRC's are reported in dmesg by btrfs. Turned out to be a single package's files were effected so the glitch must have occurred during a package install/update. I just renamed the target directory and re-installed the package, but I can't delete the bad files without unmounting the whole filesystem (booting to another device) and then fixing the CRCs. SInce we're talking about bytes not megabytes, I haven't bothered yet, but the bad CRC's also cause "Stale File Handles" after reboot so the Send/Receive fails. No more backups until I fix it. Could have been worse had it been a more critical package. Interesting thing was the files were still readable (but not delete-able) and usable until a reboot, so maybe even a critical package would be fixable if you got to it right away. The fsck portion of btrfs is still under fairly heavy development.

[oshunluvr]

Yeah, big diif from 14.04 to 15.04:

stuart@office:~$ ll /sbin/fdisk
-rwxr-xr-x 1 root root 267176 Feb 23 03:21 /sbin/fdisk
stuart@office:~$ ll /mnt/samsung/@Kubuntu_14_04/sbin/fdisk
-rwxr-xr-x 1 root root 99488 Feb 12 13:53 /mnt/samsung/@Kubuntu_14_04/sbin/fdisk

[Qqmike]

sorry, Feathers, looks like I am also guilty of hi-jacking

[Qqmike]

well, I guess this is Stupid Morning for me, I'm not getting it, seems to be many fdisk's around:

mike@mike-desktop:~$ sudo fdisk -l /dev/sda
GNU Fdisk 1.2.5
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

and it's giving me warnings about cylinder boundaries I have never seen before.

What fdisk do I need? (yeah, I did the apt-cache search etc., and Muon etc.)

EDIT: apt-get tells me I already have the latest version of util-linux installed, but, clearly my fdisk sure doesn't look like yours.

Kubuntu 14.04, btw.