Btrfs Gets More RAID 5/6 Fixes In Linux 4.16

[phoronix]

Phoronix: Btrfs Gets More RAID 5/6 Fixes In Linux 4.16

The Btrfs file-system updates were mailed in and subsequently pulled today to the mainline tree for the Linux 4.16 kernel merge window...

http://www.phoronix.com/scan.php?pag...For-Linux-4.16

[rukur]

When is the year of BTRFS 5/6 ? I've been on and working well raid 1 for a few years now.

[jpg44]

It is great to see Btrfs maturing so nicely. Its clearly the filesystem of choice now on Linux. We've been playing catch up with ZFS but its finally good to see this it becoming competitive with the other offerings out there. Btrfs ought to consider some kind of versioning support if it doesnt have this already (this is different from snapshots as versions store old versions more continuously rather than periodically).

[arbition]

While it might be that it should be the filesystem of choice, Red Hat dumping it in favour of extending XFS paints a different picture. I use BTRFS quite widely myself, so I wish it were the case.

[bachchain]

Did they ever fix that raid 5 data sinkhole

[Zan Lynx]

It is great to see Btrfs maturing so nicely. Its clearly the filesystem of choice now on Linux. We've been playing catch up with ZFS but its finally good to see this it becoming competitive with the other offerings out there. Btrfs ought to consider some kind of versioning support if it doesnt have this already (this is different from snapshots as versions store old versions more continuously rather than periodically).

There's a guy who wrote an inotify script to do that. It was in Python. It watched for inotify close events and copied the file to a hidden version directory using CoW reflink. It did have a problem if the file got modified during the copy.

I'll have to see if I can find the Github link for it.

[starshipeleven]

Btrfs ought to consider some kind of versioning support if it doesnt have this already (this is different from snapshots as versions store old versions more continuously rather than periodically).

I'd rather not embed this in a filesystem, what's wrong with current solutions?

[rubdos]

I'd rather not embed this in a filesystem, what's wrong with current solutions?

I think jpg44 means snapshots accessible at every write/change, instead of having to trigger a snapshot. `snapper` is quite awesome though.

There's a guy who wrote an inotify script to do that. It was in Python. It watched for inotify close events and copied the file to a hidden version directory using CoW reflink. It did have a problem if the file got modified during the copy.

I'll have to see if I can find the Github link for it.

Making such a thing into a daemon that calls `btrfs snapshot` shouldn't be too difficult, right?

[Charlie68]

Using Btrs since I switched to openSUSE and I find it impressive, having the ability to restore the Snapper system is something I never want to give up!

[Michael_S]

I am confident btrfs will become as mature and stable as ZFS eventually, but I'm not confident that time is now. I've been using it on maybe ten drives at home (I have a lot of computers) without problems for years, but I don't use RAID at all. Just volumes + cron job rsyncs. It's a hassle, but that way I can move drives between computers or into an external drive enclosure without fear of breaking anything other than those same rsync jobs.