XFS Copy-On-Write Support Being Improved, Always CoW Option

[phoronix]

Phoronix: XFS Copy-On-Write Support Being Improved, Always CoW Option

One of the recent XFS innovations under work and maturing with time has been Copy on Write (CoW) support for this mature Linux file-systems. The XFS CoW support continues to be improved upon and an "always CoW" option is being prepared to always force this behavior...

http://www.phoronix.com/scan.php?page=news_item&px=XFS-2019-Copy-On-Write-Better

[macemoneta]

BTRFS is supported on pretty much every distribution at this point. It's simply not the default at installation (except for SUSE). Google using BTRFS for Chromebooks is arguably "acceptance". Major corporations use it. We've been running it (RAID1 and single) 24/7/365 for 7-8 years without issue, through multiple hardware failures.

[doublez13]

BTRFS is supported on pretty much every distribution at this point. It's simply not the default at installation (except for SUSE). Google using BTRFS for Chromebooks is arguably "acceptance". Major corporations use it. We've been running it (RAID1 and single) 24/7/365 for 7-8 years without issue, through multiple hardware failures.

I was not aware Google was using BTRFS on the Chromebooks. Do you have a link?

[Britoid]

BTRFS is supported on pretty much every distribution at this point. It's simply not the default at installation (except for SUSE). Google using BTRFS for Chromebooks is arguably "acceptance". Major corporations use it. We've been running it (RAID1 and single) 24/7/365 for 7-8 years without issue, through multiple hardware failures.

Last time I tried to install Fedora it wouldn't let me use brtfs for / or something like that.

[kaszak]

Will this change the on-disk format? I was looking into converting my partitions to XFS, but i don't know if i should wait if the v5 format gets deprecated soon.

[starshipeleven]

Will this change the on-disk format? I was looking into converting my partitions to XFS, but i don't know if i should wait if the v5 format gets deprecated soon.

I don't see why they would need to change the on-disk format.
The basic concept of CoW is just "write all new data in free space, THEN update the filesystem metadata to mark the new data you just wrote as current, and mark the old data as free space". THere is no need to store additional information in the on-disk format.

[Jabberwocky]

Last time I tried to install Fedora it wouldn't let me use brtfs for / or something like that.

Anaconda can be "special" at times. I have had some really strange partitioning woes with it where it simply would block installation without explanation. Lack of installer feedback has led me not to report any bugs. I wasn't missing efi or anything obvious and not using a complex setup.

On this workstation however I have a relatively complex setup. Fedora 28 with btrfs on NVMe /, luks/ext4 on SATA3 SSD for some virtual machines, and finally xfs on SATA3 SSD for databases and arbitrary data. I don't have a need for CoW on xfs anytime in the foreseeable future.

[polarathene]

Would the CoW support for XFS mean it'd get slower perf using that feature? Similar to BTRFS?

ZFS also does CoW right? But has some differences from how it works compared to BTRFS where it doesn't share the same issues as BTRFS does with running Databases or VMs (without disabling CoW)? If so which type of CoW is the XFS support more likely to be?

[gbcox]

BTRFS is supported on pretty much every distribution at this point. It's simply not the default at installation (except for SUSE). Google using BTRFS for Chromebooks is arguably "acceptance". Major corporations use it. We've been running it (RAID1 and single) 24/7/365 for 7-8 years without issue, through multiple hardware failures.

Michael's statement in the article is still accurate...."With Btrfs adoption not taking off like some had hoped years ago..."

BTRFS missed the boat... Kent Overstreet summed it up pretty well:

"btrfs, which was supposed to be Linux's next generation COW filesystem - Linux's answer to zfs. Unfortunately, too much code was written too quickly without focusing on getting the core design correct first, and now it has too many design mistakes baked into the on disk format and an enormous, messy codebase - bigger that xfs. It's taken far too long to stabilize as well - poisoning the well for future filesystems because too many people were burned on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs multiple times and had to switch at the last minute, and server vendors who years ago hoped to one day roll out btrfs are now quietly migrating to xfs instead)."

Redhat is deprecating BTRFS - and that means the vast majority of Corporate Linux installations won't be using it. As you mention, the only distribution which is using it as default is SUSE - and that means the vast majority of people won't go out of their way to install it - and it's very doubtful other distributions will be choosing it as their default.

[starshipeleven]

Would the CoW support for XFS mean it'd get slower perf using that feature? Similar to BTRFS?

Possible, but not as bad as btrfs as it's not also doing checksums and other stuff, so its CoW is lighter.

ZFS also does CoW right? But has some differences from how it works compared to BTRFS where it doesn't share the same issues as BTRFS does with running Databases or VMs (without disabling CoW)?

ZFS has much much much better caching systems (basically integrates something like bcache), its RAID actually works correctly (i.e. it reads from both drives in RAID1), and it is more optimized overall.

If so which type of CoW is the XFS support more likely to be?

It's going to be lighter as it lacks most of the features these other two filesystems support, but it's hard to speculate much more than this.