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

Open
votdev opened this Issue May 9, 2018 · 70 comments

Comments

Projects
@votdev
Collaborator

votdev commented May 9, 2018

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:

  • It will be possible to implement quota per shared folders which is currently not possible, or at least for the volume that contains the shared folder.
  • It will be possible to support the ability to enable/disable execution permission per shared folders. Now this is only possible via custom env variables per volume.

Plugins that are using shared folders are not affected by these plans because the shared folder handling will not be changed at all.

@votdev votdev added feature 5.x labels May 9, 2018

@votdev votdev self-assigned this May 9, 2018

@votdev votdev added this to To do in 5.x May 9, 2018

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented May 9, 2018

Please use btrfs for the OS drive as well.

@votdev votdev changed the title from Use BTRFS as default filesystem to Use BTRFS as default and only filesystem for data pools May 9, 2018

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented May 9, 2018

I like this idea especially if you keep zfs as a possibility when designing it.

@davidh2k

This comment has been minimized.

davidh2k commented May 9, 2018

Does that mean that you even consider dropping support for using ext4/xfs/... as data drives?

@votdev

This comment has been minimized.

Collaborator

votdev commented May 9, 2018

@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.

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented May 9, 2018

@votdev database structure will not be touched? Are you going to stay with xml?

@votdev

This comment has been minimized.

Collaborator

votdev commented May 9, 2018

@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.

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented May 9, 2018

@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.

@adaxi

This comment has been minimized.

adaxi commented May 9, 2018

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.

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented May 9, 2018

BTRFS has issues with RAID56, the developers do not recommend using this kind of RAID.

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.

@adaxi

This comment has been minimized.

adaxi commented May 9, 2018

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.

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented May 9, 2018

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.

@subzero79

This comment has been minimized.

Contributor

subzero79 commented May 10, 2018

LUKS should be part of openmediavault also. Is built in kernel and has very good integration with systemd.

@modelrockettier

This comment has been minimized.

Contributor

modelrockettier commented May 12, 2018

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.

@DisasteR

This comment has been minimized.

DisasteR commented May 14, 2018

Btrfs dont support bloc device that's a bad move for me...

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented May 14, 2018

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.

@Ansem93

This comment has been minimized.

Ansem93 commented May 16, 2018

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??

@subzero79

This comment has been minimized.

Contributor

subzero79 commented May 16, 2018

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

@Ansem93

This comment has been minimized.

Ansem93 commented May 16, 2018

Understood!
Just a request: if the support to ext3/4 will be dropped, can you please make some giant post on forum and blog? I don't think I'm the only one with OMV4 and an ext4 partition with data.

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?).

@danielbibit

This comment has been minimized.

danielbibit commented May 16, 2018

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.

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 ?

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented May 16, 2018

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.

@alpapad

This comment has been minimized.

alpapad commented May 19, 2018

Can we get a decent btrfs plugin (like the zfs one) for 4.0?

@DisasteR

This comment has been minimized.

DisasteR commented May 23, 2018

@ryecoaaron you cannot create bloc device on btrfs. Like logical volumes on lvm.

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented May 23, 2018

@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.

@DisasteR

This comment has been minimized.

DisasteR commented May 23, 2018

@ryecoaaron i'm using lvm to present block locally or over iscsii to be used as vm disks.

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented Aug 1, 2018

@unquietwiki another option might be VDO (https://github.com/dm-vdo) since you can use any filesystem on top of it.

@unquietwiki

This comment has been minimized.

unquietwiki commented Aug 1, 2018

@ryecoaaron That's the Permabit stuff I kept hearing a while back; thank you for that find! 👍 Looks like it still has a ways to go in terms of being fully integrated with the current toolsets. Debian has it as a wishlist item. Rockstor would probably be a better fit for using it right now.

@ryecoaaron

This comment has been minimized.

Contributor

ryecoaaron commented Aug 1, 2018

@unquietwiki Yeah, I'm not sure why it needs so much development since it was a mature product. I just hope redhat doesn't make it too difficult to use on other OSes since permabit did have an Ubuntu package. I keep watching it because I think it would awesome. As for rockstor, my few tests have never turned out good (not really a fan of rpm/yum/dnf based distros though).

@molnarti

This comment has been minimized.

molnarti commented Aug 1, 2018

it's not in the interest of the user which technology nor filesystem is used to do so

that could be the case for an off-the-shelf product aimed for the generic users without any technical knowledge, e.g. the lowest of the low-end offering. on the other hand solutions like OMV (or FreeNAS, NAS4Free, Rockstor for that matter) are rather for users who are not satisfied with the ready made products and want to customize their experience in terms of both HW and SW, considering multiple migration paths and use-case scenarios. forcing a certain way that "just works" in the style of Apple may have it's target audience, but not in the DIY NAS community. of course if votdev would intend to bundle OMV 5 with a dedicated HW this development path would make more sense

@votdev

This comment has been minimized.

Collaborator

votdev commented Aug 2, 2018

forcing a certain way that "just works" in the style of Apple may have it's target audience, but not in the DIY NAS community.

That's your opinion, i have a different one about that. And surely others, too.

of course if votdev would intend to bundle OMV 5 with a dedicated HW this
development path would make more sense

Be sure there are no plans for that. The only reason is to reduce problems, bug reports and make it easier for the devs AND users.

@xmstspider

This comment has been minimized.

xmstspider commented Aug 2, 2018

The only reason is to reduce problems, bug reports and make it easier for the devs AND users.

First thank for the great effort @votdev , I am the OMV user since 0.3 days and in my lab OMV4 currently powers about 30TB of data, mainly XFS on RAID5.

To your arguments:

Shared folders will be implemented via subvolumes. Thus it is easy to create snapshots with the ability to rollback to a previous state.

Definitely a plus to have a BTRFS

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.

Unfortunate decision IMHO, I don't have resources to migrate 30TB+ from XFS to BTRFS.

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.

So users with USB disks connected to OMV may start looking elsewhere?

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).

I don't like this approach much, since it will kill any effort to add EXT4/XFS support in form of plugins.

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.

Don't take me wrong, but people are not choosing OMV to manage storage in CLI.

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.

So even if I welcome to have a BTRFS support, I still trust more the XFS/EXT4 combo (and RAID5/6 is a must for me) and if it would disappear, then I might reconsider another solution, not to be happy about it, since I really like the way OMV works.

OMV 5 seems to be a step towards a COTS solution targeting common users, but IMHO these types of users barely use NAS solutions.

@votdev

This comment has been minimized.

Collaborator

votdev commented Aug 2, 2018

Thx for all comments. At the moment these are all considerations, nothing is final.

@unquietwiki

This comment has been minimized.

unquietwiki commented Aug 2, 2018

@votdev Thank you for hearing us all out on this stuff. It's appreciated. 👍

@unquietwiki

This comment has been minimized.

unquietwiki commented Aug 10, 2018

The later versions of Samba have a btrfs-subvolume module; that may be required to be enabled for avoiding some errant log & write behavior. Just a heads up. 👍

@f5alcon

This comment has been minimized.

f5alcon commented Aug 17, 2018

Is there any update on this? I am planning a new NAS and was going to use an mdadm raid 6 with btrfs on top, but it doesn't sound like this would provide an upgrade path and I don't want to be stuck on OMV 4 for 5 years until I build a new box. Is there a way to use native btrfs currently so it can import into 5?

@f5alcon

This comment has been minimized.

f5alcon commented Aug 20, 2018

BTRFS has an issue with its RAID 10 implementation in addition to RAID5/6.
In hardware raid

sda sdb are mirrored and striped with sdc and sdd mirror. If one drive in either mirror fails it is fine.

In BTRFS because of 1GB blocks there is more risk I think, if a file is 3GB

block1 sda sdb->sdc sdd

block 2 sda sdc->sdb sdd

block 3 sda sdd->sdb sdc

So if any 2 drive fail the file is lost.

In hardware raid 10 with 4 drives and one failed there is a 1/3 chance that the second failure is in the same mirror with 6 drives 1/5, 8 drives 1/7. The risk data loss goes down the wider the array. With this implementation the chances go up the wider the array since any 2 failures cause data loss.

@vfrex

This comment has been minimized.

vfrex commented Aug 25, 2018

Hi, just to share a different perspective if warranted. I spend an inordinate amount of time on forums talking about home server configuration and often recommending OMV 4.x. And personally use BTRFS and try to keep up with the mailing list. But there is still an uncomfortable number of people reporting broken FS on recent kernels using "safe" RAID modes under BTRFS. Plus databases are still problematic for BTRFS and performance isn't great. And correct me if I'm wrong, but I don't think there is a timeline for fixing the RAID5/6 write-hole issue.

BTRFS is improving quickly, but there are also other options emerging quickly. XFS is adding features like CoW, LVM is very actively developed, BCacheFS is being mainlined, and Stratis is on its way. Heck Synology hacked a way to scrub a mdadm array over BTRFS volumes. That isn't even considering the distributed FS that some people are experimenting with on SBC devices. As unique and awesome as BTRFS is today, it is rarely my first recommendation for home users. And with the Linux multi-device storage landscape becoming much more competitive over the next year, the number of scenarios where BTRFS is the best option could decline.

So, as much as I'd love to see OMV build in features around BTRFS in 5.x, the reason I think OMV gets recommended today is the flexibility combined with ease of use compared to rolling your own from scratch. That positioning gets shaky if you lose the flexibility, particularly with options like cockpit-project in the wings. Maybe I have too narrow a perspective how the world uses OMV, but with so much in the Linux storage pipeline, why jump the gun? If that flexibility comes at the cost of developer time, I understand. But I'd hate to see OMV lose a chunk of its user base.

@f5alcon

This comment has been minimized.

f5alcon commented Aug 25, 2018

@vfrex, it caused me to not move to OMV because of the uncertainty.

@unquietwiki

This comment has been minimized.

unquietwiki commented Aug 25, 2018

@vfrex That's a nice summary of things going on right now. And TIL about https://stratis-storage.github.io/ 👍

@esbeeb

This comment has been minimized.

esbeeb commented Sep 2, 2018

FWIW: Please let EXT4 remain a 'first class citizen" filesystem in OMV. Chris Fisher of Linux Action News made a big bet on btrfs a few years ago, got bitten hard, and now considers it to be "a joke." Filesystem stability is very important to me. I've been using linux for 20 years, have a degree in Comp. Sci, and 5 years experience as a Linux Sysadmin. Old-schooler here. If I can't use a filesystem like EXT4 which I trust 100% as a first class citizen in OMV, then I will not want to use OMV at all.

Please give me stability, and IMHO new-fangled features should be plainly marked as "Beta", and users must opt into them, thereby signing up for any big problems that might come their way. In this way, OMV devs can cover their butts, saying that users with any future btrfs filesystem problems "asked for it".
Also please note how virtually all linux distros out there use EXT4 as their default filesystem. I think that says something.

@esbeeb

This comment has been minimized.

esbeeb commented Sep 2, 2018

After reading this page, I'm feeling a little more ready to trust BTRFS, however, can the OMV devs perhaps assure end users that they'll try to keep the linux kernel right up-to-date somehow (automating new, stable kernels getting updated to somehow, so that the BTRFS functionality stays the newest and best)?

I ask this, after noting that it says here:
"The Btrfs code base is under heavy development. Not only is every effort being made to ensure that it remains stable and fast but to make it more so with each and every commit. This rapid pace of development means that the filesystem improves noticeably with every new Linux release so it's highly recommended that users run the most modern kernel possible."

@esbeeb

This comment has been minimized.

esbeeb commented Sep 2, 2018

After considering how you are going to deeply integrate with BTRFS features (in OMV 5), I say, good on 'ya, and take back my pessimism. Volker, please Rock On. Once I opened my mind, I think I can see your vision now.

Since you plan to drop RAID support in OMV 5 (good move, I say), you seem to be steering clear where BTRFS' Achilles heels lie.

I sure wouldn't miss RAID, personally, since my use-case for OMV from the get-go is a modest, simple one: a single SATA drive attached to an Espressobin SMB, then an external USB 3.0 drive, backed-up-to using your "USB Backup" plugin (which is a sort of like a poor-man's ersatz RAID disk, in the sense that it gives some cheap and sensible redundancy, with decent disk throughput over USB 3). Then BTRFS can blow up if it really wants to, as the backed-up-to USB disk would have, say, NTFS or EXT4 on it, thereby "insuring" me, and my data loss would be minimal.

PS: I guess if someone wanted a plain-jane, EXT4-centric, more conservative variant of OMV, they could always fork this project.

@vfrex

This comment has been minimized.

vfrex commented Sep 2, 2018

@esbeeb SuSE uses BTRFS for the root partition and has been contributing significantly to code. Snapper is a very cool project, LXD (a Canonical project) makes use of BTRFS features by default, Rockstor seems to do a good job with a BTRFS-specialty OS. I don't think using BTRFS by default is a bad idea from a stability standpoint and I think it will continue to improve in many respects. But there is still the issue of databases, fragmentation, and performance in some cases.

Just to note, Stratis bumped to v0.9 this weekend and I would guess it hits 1.0 before OMV 5.x is released. I'm not smart enough to understand whether this layered approach is good or bad, but I wonder if this is a reasonable plan C for multi-device people worried about BTRFS that can't handle the inflexibility of ZFS? If Stratis deals elegantly with LVM and CoW and encryption and dedupe and tiering/caching,,and exposes management through an API, that seems to be a substantial upgrade from the md and lvm plugins as is, and maybe fits within the proposed 5.x framework?

@lukjak

This comment has been minimized.

lukjak commented Sep 10, 2018

Hello,

By all accounts, it does not look good to me. I use ext4, brtfs and NTFS on external drives with OMV. Just my two cents.

@votdev votdev changed the title from Use BTRFS as default and only filesystem for data pools to Proposal: Use BTRFS as default and only filesystem for data pools Sep 10, 2018

@godfuture

This comment has been minimized.

godfuture commented Sep 27, 2018

Why dropping RAID? What will be the alternative to protect against hardware failure in OMV 5.x?

@unquietwiki

This comment has been minimized.

unquietwiki commented Sep 27, 2018

@godfuture I would imagine cloud backup would replace that role, in some fashion. Also, btrfs RAID 0/1/10 is known good; but there's some FUD about a RAID 5/6 bug, that may have been fixed in recent kernels.

@Ansem93

This comment has been minimized.

Ansem93 commented Sep 28, 2018

@godfuture If you're building your NAS for home I suggest you to use a sync function between two hdd instead of RAID1, this way if an hdd fails you won't lose your data. You can also detatch an hdd every time you want.

@godfuture

This comment has been minimized.

godfuture commented Sep 28, 2018

@unquietwiki
Alright. Even I am not so amused to cloud backup, this sounds like a solution to average users. I still don't understand why the widely used and loved RAID 5 and 6 isn't fixed till now. If it hasn't been fixed all these years, what should be different nowadays? If someone knows, I am really interested in blogs about this famous bug to understand what and why...

@Ansem93
Sync is not the same solution as a RAID, because failover isn't as easy and instant as with RAID1.

If Btrfs will take over, I would be glad to have a migration to "plain" debian. Then at least I have an up to date server OS to keep things running the old way. I think that could be a good trade off for holdouts.

@vfrex

This comment has been minimized.

vfrex commented Sep 28, 2018

@godfuture
If you have the patience, here is a recent mailing list thread that discusses the state of affairs with regards to btrfs raid5/6. It goes well over my technical understanding at times, but makes sense and it seems things are moving in the right direction: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg79525.html

@godfuture

This comment has been minimized.

godfuture commented Sep 28, 2018

@vfrex
According this mailing list, famous btrfs issues around the RAID56 mode got fixed. They are speaking about kernel 4.18, including latest backports to 4.17. So these are really some hot potatos, which is the reason they emphasize btrfs RAID implementation did not enjoy too much testing compared to other solutions. So far so good.

The left known issue seems to be related to ALL parity based RAID implementations (not only btrfs) in degraded mode and ungraceful shutdown. This sounds to me like mdadm users could face the same problem, and thus considering backup an acceptable risk.

What about encryption? LUKS is only working on block devices...does someone know if btrfs will be capable to combine RAID5 or 6 with encryption?

@vfrex

This comment has been minimized.

vfrex commented Sep 29, 2018

@godfuture

For some reason, I think I read mdadm had a fix a few kernel versions ago. Also, something about btrfs's architecture makes the write hole bug more likely. I don't have any sources to link to so my brain might have inadvertent fabricated.

I just tested OMV4 using two HDD in the following order: LUKS plugin -> unlock through plugin -> formatted each btrfs through OMV -> from cli mkfs.btrfs -f -m raid1 -d raid1 /dev/mapper/crypt1 /dev/mapper/crypt2 -> mounted through OMV.

Have not tested extensively, but after a reboot and unlock of the devices, OMV does not seem to successfully mount the btrfs array. I can mount manually by the cli but the array continues to show as unmounted in the OMV File Systems tab. Can confirm manually mounting makes the array readable/writable. Usable but cuts away some of OMV's functionality (ie can't seem to create an smb share through OMV GUI on the array that OMV doesn't think is mount). Not sure where OMV is getting tripped up on this and perhaps it is solvable manually with /etc/crypttab, but you'd have to be careful to avoid having btrfs assemble the array before all drives are unlocked/visible.

So I guess to answer your question, you can create btrfs within LUKS encrypted drives and use btrfs to create a raid array. I would hope a btrfs focused release of OMV would resolve the problem I described, if it happens to be widely experienced.

@manuelfink

This comment has been minimized.

manuelfink commented Oct 9, 2018

Hi guys,

Great joice to go for btrfs. I'm pretty new to omv but this is the point for me considering omv instead of freenas since I expect btrfs to be the better joice than zfs.

Good job your doing here!

Is were any timeline for deeper btrfs support as of today or any plugin available for omv4?

@f5alcon

This comment has been minimized.

f5alcon commented Oct 10, 2018

Hi guys,

Great joice to go for btrfs. I'm pretty new to omv but this is the point for me considering omv instead of freenas since I expect btrfs to be the better joice than zfs.

Good job your doing here!

Is were any timeline for deeper btrfs support as of today or any plugin available for omv4?

Why do you expect btrfs to be better? It hasn't been for the past 5 years, it has some huge flaws, raid expansion is the only real benefit over ZFS.

@niko2

This comment has been minimized.

niko2 commented Nov 6, 2018

First of all, thanks a lot @votdev for the great work during the past years.

I am still happy with an OMV 0.2.7.4 as main NAS (It is Debian 6 old-old-old-stable, shame on me !).
I use also some 2.x on arm devices, plus 3.x and 4.x on other NAS, some physical ones and some virtual ones. I have been using XFS on top of lvm and Linux Raid6 with no issues since years.

I am pretty sure BTRFS has improved stability, I really understand your statement and I really support disruptive initiatives, but I wonder what is the real motivation ?

IMO, a NAS should be the most stable piece of hardware/software in the data center or @home, with rock-solid technos and a minimum effort to maintain. Personally, I don't see the point of using snapshots for nearly cold storage. Is it really too much work to provide all storage options ?

If you definitely decide to make the turn, I would encourage you to support 4.x on next stable Debian version and let your users play with BTRFS with 5.x

My last concern is about the couple Debian/BTRFS. Unless Debian has changed a lot, it is not providing the most up-to-date kernel, so I hope it will be recent enough to provide enough BTRFS stability...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment