Is there btrfs support planned for omv6?

I had read that btrfs was going to be the flagship filesystem for omv6, so I was excited to spin up a copy of omv6 today. I got to playing around with it in a VM and it seemed btrfs was still a second class citizen.

The raid options are all mdadm, I cant see a way to do btrfs raid arrays in the gui.
Ok I manually created the array on cli.
Mounting the btrfs volume mounts it will none of the optimizations like no atime or compression. (defaults)
Changing the mount options through config.xml and remounting it results in the filesystem going missing after every reboot.
The gui mount options only seem to pick up one disk from the array, and that disk seems to be random.
The space usage and capacity numbers are not correct for the array.

I was eyeballing using this for a NAS for my family, but it is in such a state that noone else would be able to fix anything when something went wrong.

Zitat von votdev

Have you ever considered that exactly the problems you are facing now with BTRFS are the reason that this file system is not fully integrated?

Don't talk to me like I'm dumb.

I am merely asking if this is going to be sorted out for omv6 or If I should just give up and move on.

Zitat von ryecoaaron

He wasn't. Since he is the developer of OMV and has only implemented basic support of btrfs, he is telling you the problems you are having is why he hasn't implemented more advanced support. English isn't his native language and you are reading into the response too much.

Unless someone else writes a more advanced plugin, I don't think you are going to see more advanced support. If you have a requirement on btrfs, then you something else might be a better option.

Fair enough, maybe its just the language barrier.

I want something that is going to have the self-healing and error correction capabilities like zfs or btrfs. You can put btrfs on an mdadm array, but it pretty much defeats the purpose of btrfs, because there is an opaque layer of abstraction between the disks and the filesystem, at least as far as btrfs knows. The error correction and self-healing cease to function.

I much prefer the flexibility of btrfs arrays where you can just sort of throw whatever disks at them you want. It really is the perfect filesystem for a home NAS. The problem is I cant find a btrfs based NAS OS. TrueNAS/freeNAS is zfs, but zfs is inflexible and you have to buy all the capacity upfront or destroy and recreate the pool to expand a vdev. You can only add redundancy to a vdev after creation.

I could build a server out to do exactly what I want it to do, but then there would be easy gui to use for the people to administer it when I'm not there.

btrfs on omv would be the best of all worlds.

Zitat von ryecoaaron

I will see if I can recreate your issue on a VM. What features would you need in a btrfs plugin to allow other to administer it? And there is a zfs plugin (although not perfect) and with zfs 2.1, you will be able to expand pools by a disk at a time.

It would need to be able to create btrfs raid arrays (really the creation only needs to be done once, not critically important but probably easier than some of these others) , mount them with optimized options(noatime, compress=, etc....) and keep them mounted, mount them in degraded mode when a disk fails, btrfs replace on failed disk, btrfs balance, after those 3 it can just be remounted normally. Btrfs scrub cron jobs to check and heal the array from corruption. Adding extra disks can be done on the fly so that wouldnt be hard to add. Disk resize can also be done on the fly. It would need to show accurate btrfs filesystem size/availability.

You have to offline them to expand partitions when replacing with a larger disk, but that could be done manually, Just getting the disk and array up and running at original capacity should be enough to admin through a gui. Like if a 2 TB disk fails and you replace it with 4TB it will just use 2TB until you expand the partition. But in the end you can add capacity to btrfs arrays pretty easily with new disks and/or replacement disks.

btrfs can also switch raid modes pretty easily, but that would be an advanced feature most people wouldnt need to use

btrfs also has good snapshot capabilities but those are less important for NAS than the ability to throw random hard disks at the array while using it's built in redundancy and error-correction.


I didnt know zfs was adding the ability to add capacity to a vdev. That has been it's weak point for a while.


As it is now I think you can create a btrfs filesystem on top of an mdadm array, but I dont know why you would ever want to do that. When I was doing my testing with it I just made 5x3 gig virtual sata drives and made a raid6 out of them.

Zitat von ryecoaaron

That's a big list. It would be a substantial plugin. Not going to say it can't happen but I haven't even ported most of the omv-extras to OMV 6.x yet and the zfs plugin is going to be a huge re-write.

Taking disk(s)/array(s) offline is something OMV doesn't like.

Yeah I know but this is what real btrfs support would mean, at least on the gui end. I had heard it was coming for omv6, even that it was going to be the central thing, but I guess that's just redditors.

Yeah but in order to repair the degraded array it has to mount it as mount -o degraded. You can delete one of your virtual disks, replace it with one of another size to simulate a disk failure. I think its btrfs filesystem show that shows you the number of the missing disk then btrfs replace start $missingdisknumber /dev/$replacementdisk fixes the array with the new one

BTRFS's documentation hasn't been updated in forever. They really need to update it. They need some PR people as well.

The raid5/6 stuff is the write hole problem which exists for every raid solution everywhere without extensive logging implemented by stuff like zfs. Extensive logging, UPS or a literal battery on a raid card is the only way around this with raid. This problem is not exclusive to btrfs in any way, but for some reason people like to talk about it with that particular implementation of raid. Zfs's is the only widely-used non-battery solution i know. Mdadm has one but noone uses it. Mdadm has this exact same write hole problem that you can plug by having a separate flash device and mounting the mdadm raid with the --write-journal specifying to journal write ahead to a separate device. In the event you encounter the write hole it can read from the journal which writes the parity and data ahead of the real writes... to try to make sense of things in the array.

Maybe this is the fault of the devs of btrfs for focusing on this universal raid problem when no other dev teams for other raid solutions do. It's just a given that the write hole problems exists with raid. Its a raid problem, not just a btrfs problem. Same thing with ECC and zfs. Zfs isnt any more vulnerable to non-ECC ram causing issues than any other filesystem, but somehow people view that as a zfs thing. Whatever is bad in ram will be bad in disk, regardless of your filesystem. That being said, mdadm, the default raid solution on OMV has the exact same problem that btrfs has with the write hole, and I'm willing to bet 99.9% of people running it aren't running a write journal device, and aren't worried about it. These types of caricatures of filesystems are more myth/misunderstanding than reality. If you pick raid 5/6 in mdadm and run it without a journaling device you are in no better situation that you would be in raid5/6 on btrfs.

I will say that in linux, if you want to see where things are going to end up watch what fedora does. They are the trendsetters of the Linux world, and they have defaulted to btrfs. SUSE already runs btrfs, and fedora does, which means eventually RHEL will, which means even more development and support when the entirety of the enterprise linux world runs it. BTRFS is more widely used and more poplar than it has ever been, it just hasn't hit the mainstream desktop world of linux yet. It's on the cusp.

I'm not sure what to make of USB performance, but there are optimizations to be made when mounting any filesystem in a particular way. I wouldn't put it past someone to just leave it as mount -o defaults (OMV does this), and be surprised when the performance isn't optimal across a different buses.
.