Is BTRFS dead? Who is the new king?

[tsu2]

On 08/04/2017 02:36 AM, Miuku wrote:
>
> psijic;2832663 Wrote:
>> Yes but it's a default system in the OpenSUSE.
> They weren't in any way involved in the development of BTRFS so it's not
> surprising they didn't choose to use it.
>
> They use other methods to achieve the same features.
>

??? Those features being? Red Hat doesn't have a BTRFS replacement or
filesystem + extras that covers what BTRFS can do.

Actually, RHEL does have a recommendation for everything we use BTRFS.
ZFS is recommended for everything we might select BTRFS to provide.

ZFS has been around for a much longer time than BTRFS, and therefor has a very long track record including extensive benchmarking and feature develoopment.

But, ZFS involves a high bar to set up properly, very different than how we use BTRFS... which is pretty much like any other more used file system.

TSU

[tsu2]

On Thu, 11 Jan 2018 10:06:02 +0000, swerdna wrote:

> V_idocq;2833345 Wrote:
>> Use ext4 for everything A filesystem that continues to create
>> snapshots like Btrfs, it seems that knowing that she is ill she
>> continually supplies her medicines
>
> What an interesting thought.

Interesting, but I think it considers only that the problem could be a
filesystem problem - and not something like an update you want to back
out or a configuration change that breaks things.

Snapshots are useful for more than just recovering from filesystem
errors.

--
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

IMO perhaps the most overlooked and unused BTRFS feature is that snapshots aren't just for rolling back entire partition file systems... it's also possible to undo individual files.

That's usually a problem because typically people don't install an "undelete" until after they find a need for it... and then you might have to take your chances with forensically recovering the file with something like photorec, hoping the file hadn't been over-written rendering the file likely unrecoverable.

TSU

[tsu2]

This is a nice but minimalistic way of doing things. I've tried to do something similar with Clonezilla but the " boot to live media" routine is just a recipe for procrastination. I'm very curious about hot snapshots of EXT4 partitions... I mean, Windows can do it with VSS on NTFS partitions. Macrium Reflect does a wonderful job, I have to admit that right now I'm using Windows + Macrium to backup my EXT4 partitions.



Fair enough. But I would really like to know what are the alternatives to Btrfs snapshot functionality on an ext4 system. The only "alternative" that I know is LVM...

Here you go...
Snapshotting EXT3 and EXT4

http://extundelete.sourceforge.net/

Once set up (very easy), snapshots are made on a schedule or you can manually invoke on demand.

TSU

[tsu2]

I'm far from a btrfs fan but some context probably helps:



I guess the main thing to take away is that RH didn't think they'd miss out by not getting devs to support btrfs integration. That, in itself, sort of indicates they don't believe btrfs will play a significant role in the future.

No,
Probably what swayed RHEL against adoption (my guess) is that BTRFS experienced some major bugs supporting Enterprise setups, like large RAID arrays... Which ordinary openSUSE and smaller SUSE/openSUSE machines wouldn't experience.

It's a matter of who these bugs effect... and it took a pretty long time to resolve those bugs.

TSU

[tsu2]

Red Hat's problem with btrfs is their incredibly old kernel. They standardize on a kernel and backport patches, but are throwing in the towel on btrfs because of a lack of expertise.

They were never a big btrfs player like Suse. Btrfs is in the kernel, it' here to stay and only improving. I keep xfs on my main data drive, but backup to a btrfs volume so I can snapshot etc. I'm also learning btrfs. Last time I talked to someone at Suse, they weren't recommending btrfs for large data drives, only the OS partitions.

This is how I have it configured and snapshots are awesome.

SUSE publishes an Enterprise Storage guide for setting up BTRFS for large data partitions/disks

https://www.suse.com/documentation/s...tor_admin.html

I've also written about using BTRFS for use other than the root partition in various Forum posts, including

https://forums.opensuse.org/showthre...51#post2843851
https://forums.opensuse.org/showthre...14#post2844814

The second link includes some comment on the RAID5/6 bug which I assume by now should have been addressed and should no longer be a problem (but I haven't actually verified).

People should also note that nowadays the openSUSE install allows you to install BTRFS in any partition and turn off snapshotting if you wish.
That would leave you with BTRFS auto-healing features(which EXT doesn't have) while eliminating any issues related to excessive or inappropriate snapshotting.

HTH,
TSU

[glistwan]

People should also note that nowadays the openSUSE install allows you to install BTRFS in any partition and turn off snapshotting if you wish.
That would leave you with BTRFS auto-healing features(which EXT doesn't have) while eliminating any issues related to excessive or inappropriate snapshotting.

HTH,
TSU

That's cool to know thanks. I was not aware of this. Maybe it's time to revisit BTRFS

[cjcox]

On 02/05/2018 11:26 AM, tsu2 wrote:
>
> cjcox;2851616 Wrote:
>> On 08/04/2017 02:36 AM, Miuku wrote:
>>>
>>> psijic;2832663 Wrote:
>>>> Yes but it's a default system in the OpenSUSE.
>>> They weren't in any way involved in the development of BTRFS so it's
>> not
>>> surprising they didn't choose to use it.
>>>
>>> They use other methods to achieve the same features.
>>>
>>
>> ??? Those features being? Red Hat doesn't have a BTRFS replacement or
>> filesystem + extras that covers what BTRFS can do.
>
> Actually, RHEL does have a recommendation for everything we use BTRFS.
> ZFS is recommended for everything we might select BTRFS to provide.
>
> ZFS has been around for a much longer time than BTRFS, and therefor has
> a very long track record including extensive benchmarking and feature
> develoopment.
>
> But, ZFS involves a high bar to set up properly, very different than how
> we use BTRFS... which is pretty much like any other more used file
> system.
>
> TSU

ZFS has a very troubled lifespan. I think your way overselling it. ZFS was
developed because Sun's "stuff" sucked big time. Their volume management was
crummy and so was their old style filesytem. With that said, Sun has always
been against HW RAID. ZFS, for Sun, killed many of their problems, problems
that the other Unix providers solved a long time ago and ZFS in all fairness is
designed for large sw disk RAID arrays. Anything else it provides is a waste
apart from that (that is, easily done in better ways).

Not saying you can't run ZFS, but as you implied, "I bet you're doing it wrong."

Just curious, would you recommend running the ZFS code base from 3 years ago?
Anyway, just food for thought.

I do have issues with BTRFS btw. But RHEL's filesystems are ext4 or XFS. The
latter added/bought because.... (you probably already know) But XFS has it's
share of limitations. I guess you could say they all do. So I disagree that
Red Hat has that feature parity BTRFS solution. I can tell you, it can't be ZFS.

[aaccioly]

Here you go...
Snapshotting EXT3 and EXT4

http://extundelete.sourceforge.net/

Once set up (very easy), snapshots are made on a schedule or you can manually invoke on demand.

TSU

Sorry to bother you, but could you point me towards the create snapshot command as well as the resulting snapshot location? (Didn't get far with the docs).

I'm looking for something similar to lvcreate -s + dd snapshot to image in external disk. My end goal is to create a backup image from a mounted / running partition.

[tsu2]

Sorry to bother you, but could you point me towards the create snapshot command as well as the resulting snapshot location? (Didn't get far with the docs).

I'm looking for something similar to lvcreate -s + dd snapshot to image in external disk. My end goal is to create a backup image from a mounted / running partition.

For extundelete,
IIRC (been a few years since I've deployed),
When you install/execute initially, it walks you through the whole process of specifying what you want to snapshot and on what schedule.

So,
It's not really in separate documentation,
IIRC the walk-through is pretty clear.
And, I've messaged with the author, he's very receptive and responsive to any questions/suggestions for improvements.

TSU

[averyfreeman]

Weird, I thought one of the greatest reasons for installing OpenSUSE were its great built-in disaster recovery system through snapper and BTRFS. It's really handy for botched upgrades, etc. too. The subvolume layout is really useful and well thought-out.

The snapshots and grub-bootable snapshots are really useful when using a rolling distro, too, because it's common for new updates to bork the system. I definitely recommend it for tumbleweed or arch (arch on ZFS rpool is a pretty beast).

I try to re-create this on CentOS, Fedora and Ubuntu when I install them. BTRFS is an option on CentOS and Fedora, just partition your own system. LVM+XFS, the default, has some nice options, too, but BTRFS really is the most feature-laden and doesn't require the extra abstraction layer LVM provides, which can cause disaster recovery issues - i.e., you can't use basic partition tools like gparted to get at your partition with LVM, but with BTRFS you can.

On Ubuntu, if you set up a BTRFS root with separate home you can do snapshots with Mint's "Timeshift" program which is not nearly as detailed as YaST with all the subvoluming, but it works pretty well. https://www.maketecheasier.com/backu...ft-linux-mint/

Also important to:

1) Make a separate /var with at least CoW turned off if BTRFS, or use XFS, EXT4

2) Have a separate /home so your personal files aren't rolled back accidentally

3) Don't fill your drive up too much - leave about 10-20% for slop space - this is an issue with ZFS, as well.

CoW FS are the way of the future once the issues get worked out. There's plenty of work being done upstream through Facebook, who use it for containers: https://facebookmicrosites.github.io...-facebook.html

It's a good read - it details how BTRFS solves some of FB's issues they saw with containerization ("Tupperware") and cgroup2 IO with EXT4. It also has a list of stuff they're working on at the end. FB is a pretty heavy hitter, dare I say... bigger than RedHat?

The premise of this thread is ridiculous on its face - BTRFS isn't going anywhere.