Is BTRFS dead? Who is the new king?

If it was not interesting, would not even deign to answer hehehehe

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. :slight_smile:


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

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. :slight_smile:

There are other tools to create snapshots, with fewer btrfs problems.
Having an external HD is better in my opinion
Btrfs should take care only of the filesystem, already in the way of partitioning during the installation and the creation of a lot of subvolumes gave me the impression of something complicated.
I had btrfs when it was put by default and I left enthusiastically doing the installer … but it caused me only problems, you say, look at the Wiki make this change go here … and then … etc, noooo I do not watch the wiki and I do not make any changes.
Maybe now it’s better … I do not know, I’m going off

Mine is just a nobody’s weight:)

btrfs is ok, had some problems with it on openSUSE and Mageia, nothing catastrophic, but also did not see any real advantage over the venerable ext4. I do think openSUSE jumped the gun a bit defaulting to btrfs, time will tell if it lasts or not.

On Thu, 11 Jan 2018 20:16:01 +0000, V idocq wrote:

>> 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. :slight_smile:
>
> There are other tools to create snapshots, with fewer btrfs problems.
> Having an external HD is better in my opinion Btrfs should take care
> only of the filesystem, already in the way of partitioning during the
> installation and the creation of a lot of subvolumes gave me the
> impression of something complicated.
> I had btrfs when it was put by default and I left enthusiastically
> doing the installer … but it caused me only problems, you say, look
> at the Wiki make this change go here … and then … etc, noooo I do
> not watch the wiki and I do not make any changes.
> Maybe now it’s better … I do not know, I’m going off
>
> Mine is just a nobody’s weight:)

Sorry to hear you’ve had a bad experience with it. For me, btrfs has
worked like a champ - no problems, use the machine every day (using it
right now, in fact).

There are obviously a million ways to do this kind of thing - that’s the
OSS way for a lot of things.

Jim


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

What tools would you guys recommend to replace Btrfs Snapshots (assuming a EXT4 or XFS filesystem)? I have a lovely/hate relationship with Btrfs.

The bad:

  1. It is kinda hard to answer questions like “How much space will I get back if I delete that snapshot?”.
  2. Automatic rebalance makes my system unbelievably slow. I often have to init3, restart kwin and Plasma after the rebalance
  3. There are so many subvolumes… Understanding the structure can be difficult.

The good:

Snapper + Installation / Administration snapshots + ability to boot to a previous snapshot often saves my bacon. Everything works very well out of the box.

Every time that I do a fresh install I feel indecisive about Brtfs.

What tools would you guys recommend to replace Btrfs Snapshots (assuming a EXT4 or XFS filesystem)? I have a love/hate relationship with Btrfs.

The bad:

  1. It is kinda hard to answer questions like “How much space will I get back if I delete that snapshot?”.
  2. Automatic rebalance makes my system unbelievably slow. I often have to init3, restart kwin and Plasma after the rebalance
  3. There are so many subvolumes… Understanding the structure can be difficult.

The good:

Snapper + Installation / Administration snapshots + ability to boot to a previous snapshot often saves my bacon. Everything works very well out of the box.

Every time that I do a fresh install I feel indecisive about Brtfs.

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.

Okay this is my crazy plan that works:

/dev/sda1 - small uefi partition
/dev/sda2 - 24 GB / ext4
/dev/sda3 - 12 GB swap
/dev/sda4 - the rest /home ext4

I boot with USB rescue and “dd if=/dev/sda bs=1M count=xxxxx | gzip -1 > date +%Y%m%d.ssd.gz” on a mounted partition on /dev/sdb (different drive!!!)

/home just gets a gzip with the normal system running.

I had to restore once, that’s “zcat filename.ssd.gz | dd of=/dev/sda bs=16K”

I guess the tricky part is computing count=xxxxx from cfdisk /dev/sda partition table, making sure the all the math pans out. The reason swap follows root is in the event of a small typo it’ll only trash swap, theoretically. It’s very nice to have a precise backup of root. I could literally swap drives, and have my system up and running in a few minutes, though with some minor email loss of about ~1 week depending on last /home gzip. Yeah I should cron that to daily …

Hmmm. I would say stick with btrfs in your case.

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…

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.

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

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

Here you go…
Snapshotting EXT3 and EXT4

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

TSU

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

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

https://www.suse.com/documentation/sles-12/singlehtml/stor_admin/stor_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/showthread.php/527927-Leap-42-3-If-btfs-is-good-why-wasn-t-it-suggested-for-home?p=2843851#post2843851
https://forums.opensuse.org/showthread.php/528096-Server-Docker-KVM-LXC-and-Backups-(snapper)?p=2844814#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

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

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.

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.