New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Use BTRFS as default and only filesystem for data pools #101
Comments
Please use btrfs for the OS drive as well. |
I like this idea especially if you keep zfs as a possibility when designing it. |
Does that mean that you even consider dropping support for using ext4/xfs/... as data drives? |
@davidh2k Yes, that's true. As mentioned above, the shared folder management will be completely focused on BTRFS features. Keeping support for other filesystems that do not have these features will make the UI and backend more complex. The shared folder database structure and handling will not be touched, so it might be possible to bring back the old functionality via plugin. |
@votdev database structure will not be touched? Are you going to stay with xml? |
@ryecoaaron Yes, don't want to change too much things in one step. And really, i don't have a good idea what to use to replace it. Until now it has done a good job. |
@votdev I agree and it is easy to fix. I don't think there is much else out there that has as good a selection of tools that can be used from all of the languages that OMV uses. |
BTRFS has issues with RAID56, the developers do not recommend using this kind of RAID. I am currently using RAID6 (using mdadm) since it is the most cost effective solution in my case. If the plan to is support only BTRFS, I don't see using in openmediavault in the future. |
Considering OMV 5.x is probably a year or more away and a patch has been developed (possibly included in 4.16 kernel), I don't see this as an issue. Volker mentions that zfs will also be possible via plugin and possibly other filesystems. I could also see a plugin for xfs once its CoW features are added and bcachefs once it is in the kernel. |
If RAID56 is mature by the release of OMV 5.x, then for sure I don't see any reason not to use it. I am just voicing my concerns since this issue has been dragging for quite some time. |
I agree but the other point is that the web interface won't allow raid5/6 creation. So, most users won't be using raid5/6 and btrfs is very stable in those cases. |
LUKS should be part of openmediavault also. Is built in kernel and has very good integration with systemd. |
I first used Rockstor on my NAS before I was bit by BTRFS stability and data integrity issues a couple years ago. That's the main reason I'm using OpenMediaVault today (since it uses MDADM + LVM + EXT4/XFS instead of BTRFS). Even though that happened a couple years ago, it will be quite a while longer before I will be able to trust BTRFS with my data again. (Although I'm quite hopeful about bcachefs) So while I understand the decision, I am a little disappointed. |
Btrfs dont support bloc device that's a bad move for me... |
In what way? You can put a btrfs filesystem on a block device. Not sure what you mean. |
I don't have any problem with using btrfs, but what about eeryone that have ZFS or EXT4 partition? There is any way to convert an ext4 RAID1 into a RAID1/mirror btrfs without losing everything?? |
Ext4 conversions are not recommended any more with kernels higher than 4.x, it was possible and worked ok. Guess people will have to use their backups to reformat. Zfs doesn’t have the door closed |
Understood! I think it would be better to warn everyone about the big change as soon as it 100% confirmed so that they have time to plan how to go from ext4 to btrfs. Hope that ZFS will still have support (maybe natively instead that with a plug-in?). |
In this case, how is this going to affect snapraid users ? I have a small mdadm raid1 array that I can convert to BTRFS without a problem, actually, is going to be really nice to have all the goodies that BTRFS has on the GUI, and it seems pretty stable in RAID1. But I also have a huge pool with mergerFS + SnapRAID, and I don't plan to change this setup anytime soon. Will OMV5 support such scenario with ease ? |
mergerfs and snapraid work on top of filesystems. So, these should still work if the filesystem on each drive is supported. But that isn't an issue for OMV. That is an issue for me to get those plugins to work on OMV 5. |
Can we get a decent btrfs plugin (like the zfs one) for 4.0? |
@ryecoaaron you cannot create bloc device on btrfs. Like logical volumes on lvm. |
@DisasteR I am well aware of that but why would you need to? btrfs does pretty much everything that ext4 on lvm does since it allows resizing, snapshots, and subvolumes. |
@ryecoaaron i'm using lvm to present block locally or over iscsii to be used as vm disks. |
This issue has been automatically closed because there has |
Hello. I have been following this since it was proposed for OMV 6.x. As someone else already said here and in another issue, there is no issue against having BTRFS specific features or usage, but against having to use BTRFS exclusively for data. I kind of skipped 6.x (not necessarily because of this issue) and I like what I am reading about upcoming 7.x features. What is the plan right now? |
With #1479 and #1480 BTRFS support has been extended in OMV. Shared folders that are on a BTRFS volume will support snapshots now. Other file systems will not be supported for shared folder snapshots because they are more complicated than BTRFS (ZFS is completely out because of the license issues). Shared folders can still be created on every file system that is supported by OMV. |
This is perfectly fine in my book. Whomever wants to have folder snapshots can use BTRFS. |
Great to hear to finally get snapshots in OMV, thank you! I was using OMV for a very long time in the past but then switched to Synology because of the snapshots missing. Now my device is running out of warranty and I planned to come back to OMV - thinking it had already implemented snapshots on BTRFS. Can you give us a hint when this will be implmented in the stable repository? |
Soon. |
Soon, meaning still in the 6.x branch? I think there will be a 7.x release sometime in the second half of the year with the new Debian release |
No, |
Thank you, this was very soon. :-) Just upgraded to 6.3.0 and the snapshot option appeared in my BTRFS shared foldes. "500 - Internal Server Error Second question: is it normal behaviour that these snapshots do not appear in CIFS shares under "previous versions" in Windows? |
Fixed with 3191ea4
Snapshots are only for backup purpose. |
That would be lovely (Windows user). |
Thank you, will report if its works as soon as the update is available.
Well, from the sight of an it specialist, snapshots are not backups but snapshots can be used as a base for making backups: Creating a snapshot for "quiescing" the file system and than backing up that snapshotted filesystem (because of the nature of a snapshot there will be no changes in the filesystem during the backup process). Thank you for that newly opened issue 1490 - yes, indeed for windows users it would be lovely like neheb wrote. |
OK, backup was the wrong wording. For me a snapshot is a tool for archiving a current state to be able to rollback if something went terribly wrong. |
I will admit that "Previous versions" support via snapshots on the cifs shares (on a netapp that takes snapshots every 15 mins) is very popular at my job. |
On my nas, every user has a samba share "user" and a readonly samba share "user.snaps". It is the easiest way to enable everyone to rollback his files himself if necessary. Works like a charm for years. Also snaps are created and deleted automatically. Is that possible using the new built-in snaps? |
it seems snapshots are not supported for mergerfs even if the underlying FS is btrfs. is there a solution planned for this scenario? |
sounds like no: https://github.com/trapexit/mergerfs#how-it-works |
No. OMV will only support BTRFS. |
@votdev does that mean mdadm support will go away? I currently plan to migrate from my btrfs raid5 setup to mdadm+raid5 for performance reasons (mdadm supports the mv_xor driver to accelerate parity calculations whereas btrfs does not). |
Software RAID will be still supported, it does not change anything. OMV will support other file systems like it does in the past, but special features like snapshots are only supported by BTRFS. Regarding MDADM, it will be separated into a plugin someday. |
alright. creating my mdadm array right now. nice to see interrupts:
I hope btrfs will get this ability soon. |
Shared folders will be implemented via subvolumes. Thus it is easy to create snapshots with the ability to rollback to a previous state.
If this feature is implemented as planned, there will be no migration path from 4.x because EVERYTHING is based on the BTRFS features then. Maybe we can implement a backend layer that allows the use of other filesystems with equal features like ZFS.
Removable devices won't be supported the way it is done in 4.x, too. The only way to import data from external devices will be the openmediavault-usbbackup plugin then. The filesystem management UI will be removed completely and replaced by a pool management UI to create/edit/resize/shrink/convert and delete pools based on BTRFS (or ZFS via plugin). The UI to manage these pools is limited to the required configuration options, e.g. creating a pool will not show ALL possible options that are available for BTRFS, instead only the most used options are displayed. Special scenarious must be done manually via CLI by power users. Note, OMV is no UI to manage BTRFS (ZFS) pools.
The MDADM management UI (Software RAID) will be removed and LVM plugin will be discontinued because it does not make sense to use BTRFS on top of MDADM and LVM devices.
Other benefits:
Plugins that are using shared folders are not affected by these plans because the shared folder handling will not be changed at all.
The text was updated successfully, but these errors were encountered: