Proposal for a improved software distribution using BTRFS

[Qqmike]

SteveRiley, my fdisk does not support GPT, is that what you are referring to:

sudo fdisk -l

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.
(etc etc)

It gave me just one of my seven partition, the ESP at sda1, nothing else.

[oshunluvr]

stuart@office:/mnt/samsung/@Kubuntu_14_04/usr/lib/perl$ sudo fdisk -l /dev/sde[sudo] password for stuart: 


Disk /dev/sde: 1.8 TiB, 2000398934016 bytes, 3907029168 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
Disklabel type: gpt
Disk identifier: FA7FD45C-E141-4DB3-A867-D80C4B41C281


Device          Start        End    Sectors  Size Type
/dev/sde1        2048       4095       2048    1M BIOS boot
/dev/sde2        4096    2101247    2097152    1G Linux filesystem
/dev/sde3     2101248 3487598591 3485497344  1.6T Linux filesystem
/dev/sde4  3487598592 3907028991  419430400  200G Linux filesystem


stuart@office:/mnt/samsung/@Kubuntu_14_04/usr/lib/perl$ sudo fdisk -V
fdisk from util-linux 2.25.2
stuart@office:/mnt/samsung/@Kubuntu_14_04/usr/lib/perl$

Works fine @here. Check your version?

Re. BTRFS: jlittle is correct actually, I misspoke a bit. EXT4 is indeed a bit faster in the I/O category, something I had stopped considering years ago. Not that myself or most of use would notice the diff in real-world uses. Personally, I think there's too much myopia in the testing world when you're talking about something as complex as a file system. There are so many things filesystems have to do that a 2 or even 20% difference is of little value if you're suffering in another more important area. But I'll uncharacteristically cease the thread jack here.

[Feathers McGraw]

But I'll uncharacteristically cease the thread jack here.

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

Now, then: the system has two copies of libfoo-1.0, a broken one and a fixed one. Can you see why this is a problem?

Yeah, the old way (update the library and see what breaks) is probably better most of the time because it forces people to be proactive about updating things.

The only exception is when some of the system is proprietary (like Maemo5 on the Nokia N900) - in this case those proprietary packages have effectively prevented users from rebasing Maemo5 on a new version of Debian, because newer C libraries don't work with key proprietary system components.

[Qqmike]

Works fine @here. Check your version?

You're right, older version. Is this gnu-fdisk? (which I installed, but it doesn't seem right) Where did fdisk go? in some utility, perhaps?

[Qqmike]

sorry, I see "fdisk from util-linux 2.25.2"

[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.

[Qqmike]

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

[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

[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.

[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?

[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.

[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.

[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...

[Feathers McGraw]

That was a great explanation, thank you

[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¿