Learning More About Red Hat's Stratis Project To Offer Btrfs/ZFS-Like Functionality

[mbello]

pal666 btrfs does have competition, it is called ZFS and available in Ubuntu and very popular in ProxmoxVE which is a great virtualization platform.

For those that say Btrfs is slow because it does so much, please explain why ZFS does the same at much faster speed. Recently, phoronix benchmarked a number of Filesystems and showed some scenarios where Btrfs was performing really slow, like two orders of magnitude slower than everyone else.

On the other hand, if Stratis is about stitching together existing solutions it is not really what we need in 2018, ZFS is really the star of the show so far and we must have something better for Linux.

[pal666]

pal666 btrfs does have competition, it is called ZFS and available in Ubuntu

linux zfs is kernel tainting crap, ubuntu can provide it because ubuntu can't support its kernel anyway. and of course linux zfs(don't confuse with solaris zfs) is even more "not ready" than btrfs.

For those that say Btrfs is slow because it does so much, please explain why ZFS does the same at much faster speed.

zfs doesn't do the same, it is inferior design to btrfs. and it doesn't do it at much faster speed either

Recently, phoronix benchmarked a number of Filesystems and showed some scenarios where Btrfs was performing really slow, like two orders of magnitude slower than everyone else.

those scenarios are databases and you don't need cow fs for database, so you just disable cow on that file and btrfs performs really well.
on the other hand you can't disable cow on one file in subj because subj knows nothing about files, so it will be really that slow (and even slower because of layering overhead)

On the other hand, if Stratis is about stitching together existing solutions it is not really what we need in 2018, ZFS is really the star of the show so far and we must have something better for Linux.

zfs is star only when you have vivid fantasy

btw, in case someone still didn't get it, subj has nothing to do with btrfs/zfs, subj is lvm2 replacement. and since it is written in rust, it is almost "rewrite lvm2 in rust"

[Vistaus]

Exactly!

I use both XFS and btrfs, and XFS is clearly the better option if you do not need snapshots. But if you do - for example, because you need to perform online backups of filesystems that are used 27/7, the btrfs retains reasonable performance, while XFS on a LVM with a snapshot crawls into basically becoming "unavailable for writing"..

What country has 27 hours in a day? :P

[F.Ultra]

pal666 btrfs does have competition, it is called ZFS and available in Ubuntu and very popular in ProxmoxVE which is a great virtualization platform.

For those that say Btrfs is slow because it does so much, please explain why ZFS does the same at much faster speed. Recently, phoronix benchmarked a number of Filesystems and showed some scenarios where Btrfs was performing really slow, like two orders of magnitude slower than everyone else.

On the other hand, if Stratis is about stitching together existing solutions it is not really what we need in 2018, ZFS is really the star of the show so far and we must have something better for Linux.

Please remind me again where this recent benchmark is where BTRFS was compared with ZFS. I don't know if I'm doing something wrong but I cannot find it having looked over all the storage articles in 2018?!

[sdack]

They also didn't opt for Btrfs since "it just hasn't yet gotten to where it needs to be in terms of stability and features."

RedHat, your leading company for open source ... running off like a sucker.

Just great how they have people's back and support the communities.

[RahulSundaram]

RedHat, your leading company for open source ... running off like a sucker.

Just great how they have people's back and support the communities.

I don't see the connection.

What makes you think that any company is obligated to support a specific filesystem commercially?

[waxhead]

it is not trying to do it, it is interface for existing block layer functionality which already "sort of" does it. existing since before btrfs or zfs. and you can't do it in the block layer properly because block layer only sees blocks, it does not know where are data in those blocks, only fs knows that. that is why zfs ("rampant layering violation") was created in the first place

Ok, that is a bit clearer. I was under the impression (keep in mind I did not fully read the design spec of Stratis) that it was like a "virtual block device" utilizing other block devices with XFS on top.
I like BTRFS, but I have always wondered if not a virtual block layer that maps "virtual offsets" to real physical offsets (almost like a MMU) would not have been better in some ways. That would allow for just about any filesystem on top while still allowing for some of the BTRFS/ZFS features.

[sdack]

I don't see the connection.

Who cares what you see and don't see? I'm not obligated to help you with your problem because we write on the same forum!

Oh snap.

... See how this works?

TL;DR: It's nice to be obligated and to have friends.

[RahulSundaram]

Who cares what you see and don't see? I'm not obligated to help you with your problem because we write on the same forum!

Absolutely. You only need to explain your perspective if you want others to understand what you are saying

TL;DR: It's nice to be obligated and to have friends.

I see where your confusion comes from now. Commercial organizations are not your "friends".

[kreijack]

I like BTRFS, but I have always wondered if not a virtual block layer that maps "virtual offsets" to real physical offsets (almost like a MMU) would not have been better in some ways. That would allow for just about any filesystem on top while still allowing for some of the BTRFS/ZFS features.

Internally BTRFS has a lower layer which maps the physical devices in logical address. The aim of this layer is to manage the chunk allocation (i.e. the unit of allocation) and the different raid profile. It is quite flexible: it allow to group (and add and remove) devices with different size using different policies (linear/striping/raid...). And you can even have different profile raid for data and metadata (eg. metadata with raid1 and data with raid6).
On top of that, there is the real filesystem, which manages the files and their attributes (owner, date, protection) grouped in subvolume (the unit of snapshot).

Having the two layer in the same subsystem, allow a lot of optimization
- in case of raid1/5/6, it is possible to recovery the data on the basis of the checksum
- in case of raid1/5/6 the resync of the raid is performed checking only the allocated data (not the full disks)
- adding a disk without needing a full rebalance (even tough is highly suggested)
- only the allocated data is moved during a balance/scrub/disk-removed operation

Unfortunately having these two layers so coupled increases the complexity of the development process; this is one (and IMHO the most important) reason why the BTRFS development is still considered in progress after so many years. But for most scenario it has to considered stable (eg single disk or raid1); there are some concern about the performance when quota and a huge number of snapshot are used together (due to the high number of reflink used), or when a balance or removing a disk is performed in case of low space scenario.

However I see some change in this process. The BTRFS crew now is focusing in stabilizing the filesystem instead of adding new features. A lot of work was done stabilizing the RAID5/6 support (which in the past was in a very bad state).

BTRFS allow the user to experiment lot of features (raid, snapshot, quota, multidevice management) which create an huge number of combination of use case; in some of these the performance are not good.
However very few filesystems (ZFS come to me) expose these functionalities, so there was not a precedent experience about how complex could be the this development.