Oracle Talks Up Btrfs Rather Than ZFS For Their Unbreakable Enterprise Kernel 6

[S.Pam]

This was not mirrored, only spanned.

[F.Ultra]

Might not be that easy. NetApp and Oracle had court case over ZFS once in the past. Well, they settled it but on what terms..?
Might it be that Oracle is tied to an non-disclosed agreements with NetApp and that's the reason it's not touching ZFS license with 10-feet pole, nor would go ahead and port it to Linux.

Oracle could afterall easily use ZFS (as similar out-of-tree port) on it's RHEL re-spin - it's not going to sue itself over copyrights!!! - and gain competitive advantage while suing everybody else who'd try to run ZFS on Linux.

But in reality it's not doing anything with ZFS at all, excepting use on Solaris. Illogical - unless there are factors in play wider public knows nothing about.

The NetApp vs Oracle suit was over patents so that should have zero impact on the copyright license of the code. NetApp claimed that they owned 7 patents that ZFS violated on "snapshot, error correction, software RAID, and file system image transfer". Of course the settlement could be a crazy one but most likely is that they decided to cross-license their patents and exchange some money. If my memory serves me Sun sued first and NetApp only brought up the 7 patents as a defence mechanism.

[F.Ultra]

Hind sight is always 20/20

At thousands of dollars/TB of SAN space, having to buy 25-30 % more, is a hard sell to management.

That is peanuts when dealing with Oracle/SUN ;-)

[Raka555]

It is (was) a well known issue, you could google for zfs performance degradation at 80% utilization.

It might be a well known issue NOW, but 14 years ago, it was not well documented.

[aht0]

How?

Quote, please.

through volsize property.

The volsize property specifies the logical size of the volume. By default, creating a volume establishes a reservation for the same amount. Any changes to volsize are reflected in an equivalent change to the reservation. These checks are used to prevent unexpected behavior for users. A volume that contains less space than it claims is available can result in undefined behavior or data corruption, depending on how the volume is used. These effects can also occur when the volume size is changed while the volume is in use, particularly when you shrink the size. Use extreme care when adjusting the volume size.

https://docs.oracle.com/cd/E37838_01/pdf/E61017.pdf

[S.Pam]

Doesn't sound very safe.

[aht0]

Hind sight is always 20/20

At thousands of dollars/TB of SAN space, having to buy 25-30 % more, is a hard sell to management.

When you are responsible for the systems it should be you who is aware of such potential problems. Simple Google query could have told you this.

Besides, it's not ZFS-specific but CoW-specific. Even somewhat logical. Something that makes heavy use of available free space for normal function is bound to slow down as free space it requires, gets scarcer. If there's no mandatory free space to be found it will bog down drastically.

Management can choose to expend their money on alternatives which perform better - when they feel it's where priorities should lie. Just tell them not to come and cry later when that better performing solution goes through unrecoverable data loss. It was their choice, afterall. It's all about trade-off's.

[aht0]

Doesn't sound very safe.

You can always opt for BTRFS Raid5/6. Shrink it any which way. If you feel its safer.

Being forced to shrink is rare case. When you can't find exact replacement disk specifiedfor the system, for example.. Generally it's the other way around, you need to increase volumes because you are running out of usable space.

Anyway, when it comes to sheer desire of criticizing things you "dislike on principle" (BTRFS vs ZFS etc), list of possible corner cases is endless. It does not prove technical solution to be inferior. Could go on and bitch about BTRFS as well, to no end. Lets behave as adults tho.

[S.Pam]

Wasn't trying to complain. My home use has benefitted from the agility of btrfs. But as you say raid56 isn't ready so far.

[Eraserstp]

But as you say raid56 isn't ready so far.

I have been using btrfs with raid 5 for four years now, and so far without any data losses, despite frequent power outages. This is home usage though, may be things would be different in the high load environment.