The default openwrt build config breaks support for most btrfs receive operations (receive fails when trying to pass acls to non-acl fs, etc.) due to missing kernel config options. Also, in order to block mount btrfs devices I have to run a "btrfs device scan" on each reboot prior to mounting. It's possible to work around the issue with startup scripts, but it would be nice for openwrt to have better btrfs support by default, at least on platforms with sufficient flash like x86_64.
Is this a feature request?
Yes, multiple feature requests, specifically btrfs acl's enabled by default and more reliable mounting on boot.
(Moved to the Feature Requests category)
BTRFS would be great for x86 devices where there is plenty of space. From my experience ext4 tends to get corrupted easily
Same. I've used ext2, ext3, xfs, ntfs, even reiserfs, ext4 - and lost data on all of them.
BTRFS has been rock-solid, and I've punished it plenty... Power outages, disk failures, abusive amounts of simultaneous reads/writes, etc.
I'd like to reinforce this request. OpenWRT needs more support for AMD64 systems. We have enough CPU, RAM and storage to have stock support for such features and not be forced to compile the kernel.
The main issue I see is lack of RAID1 support, neither mdadm nor Btrfs. When we build a PC or buy an AMD64 appliance to use as router, we're looking for more advanced device than a WiFi router, and the most desired feature on a server is RAID1 redundancy.
On most Lix OS, we can just build initramrd with the modules right from the package manager and use stock kernel which is tested and stable. We understand OpenWRT is designed to be extremelly lean to fit on WiFi devices, so IMHO the simplest solution would be to have RAID file system drivers compiled into stock kernel.
The solution to make OpenWrt more lean - is to compile something else into the Kernel?
That's an nteresting point of view.
To be clear - if one seeks a more advanced router, they're seeking a server?
1 Like
"Better BTRFS support" is not done with one or two unspecified kernel options, a lot more effort would be required on grub2, initramfs, kernel, procd and sysupgrade to make this worthwhile. While there certainly is a lot of potential for improvement, especially for x86_64 (a/b upgrades, more dynamic partitioning support and -yes- BTRFS, etc.), handwaving the actual implementation step away and expecting other to step up to this is unlikely to be successful.
If you want to see change or 'improvements', the best approach would be to provide a PR with your changes so there is some substance for actual discussion (given the impact, that won't be a quick route either, but it's the only realistic one - concise goals/ commit descriptions backed by the actual code changes that could be scrutinized). With x86/ x86_64 being a fairly generic target, there is some concern to touch things (unique to x86) that are proven to work and are upgrade safe, because there are quite some risk involved (and testing thrown out by fundamental changes); not all BIOS/ UEFI versions are actually sane…
I'm running mdadm with RAID1, it is supported not just on x86 but other OpenWRT targets too.
1 Like
Would whatever Turris does with the ARM based Omnia help with any of this?
As ARMv7 with u-boot is very different to (BIOS || UEFI) && (grub-pc || grub-efi) && (GPT || DOS) not really, the bulk of works lies elsewhere.
Sorry I concatenated 2 different ideas on the same phrase and made it confusing.
I mean that AMD64 systems, even appliances with Celeron CPUs, are much more powerful than Wifi devices, because of that AMD64 target should have more features enabled by default compared to Wifi.
We understand that general OpenWRT must be lean and few features can be enabled, but that's not the case with AMD64. Therefore, it's simpler to have features common on AMD64, like RAID1 and Btrfs, enabled by default.
I didn't understand the question. Aren't all routers considered servers?
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.