Hello all,
I am new to OpenWRT (though not new to Linux in general) and have installed OpenWRT on a MyBookLive NAS. This - so far - has worked very well, including custom rootfs size using the image builder and a custom package list using Ubuntu 22.04 as a build system.
I have some questions though.
How do sysupgrades work with custom images / additional partitions?
I had to run "gdisk --mbrtogpt" to be able to create >2T partitions at all, will a sysupgrade rewrite the partition table, or just the partition contents?
Is there a graphical way to create Samba users with passwords in smbpasswd? luci-app-samba4 can manage shares, but not users & passwords.
Alternatively, is there a good documentation about how to create (and test) LuCI apps? I'd then have a go at creating my own user management app for LuCi.
I am getting about 25 MB/s write transfer from the MBL, both with samba4 and ksmbd packages. I tried the "extra tuning" option in LuCI, the "sendfile" flag in smb.conf, played around with various "socket options", but could not get higher performance out. CPU is maxed out with smbd during transfer. Protocol according to smbstatus is SMB3_11, no encryption, no signing.
I seem to remember the original MBL firmware could do ~40MB/s, also using Samba. What else can I try to increase throughput here?
ppc found in MyBook Live like to have large pagesize . OEM was 65536 but currently is 4096 .Lot's of space was wasted in RAM and HDD but CPU liked this way.
Not much to do apart custom compilation with 64k pagesize and large disk cluster.
That was my main reason behind not move outside OEM years back when I had mybook live device myself.
Thanks! I did some experiments which seem to confirm that a kernel change would be necessary to reach the original MBL I/O performance.
Original MBL distribution could do ~40 MB/s
No amount of Samba configuration parameters went above ~25 MB/s with OpenWRT
Just changing ext4 blocksize using mkfs.ext4 -O bigalloc -C 65536 also did not help (neither in combination with above)
various kernel boot parameters also did not help
So I'm wondering ... Since (probably) the kernel configuration is different for each device anyway, would a kernel variable which changes the blocksize to 64kb just for MBL devices stand any change of getting into the official OpenWRT git?
Also, would this be sufficient? Or would we have to recompile all the userspace as well?
If the chance of getting into git is there, I' would have a go at compiling a custom kernel and offer to commit the changes if it works out. Other distros also have a 64k flavour of architectures which support this natively: https://lists.ubuntu.com/archives/kernel-team/2020-September/113596.html
OpenWRT seems to be the only viable chance of putting an up-to-date NAS-like OS onto the very popular WD devices. All other NAS firmwares require much more potent hardware to run at all (starting at >>1G of memory). So we have a serious USP here with OpenWRT which might warrant some optimization.
My 2 cents. ZyXEL had a NAS (the NAS5xx) based on the Mindspeed Comcerto 2000, which also supported both 64k and 4k pages. Originally the NAS used 64k pages. But after about 2 years the newer firmware used 4k pages. The speed didn't decrease. Maybe because the network was limiting, and not the CPU.
There was another drawback, with 4k pages the biggest volume size was 16TiB, which caused some upgrading troubles, but that's another story.
On the 64k kernel most '4k userspace' software couldn't run. With one exception. The firmware of a WD nas using the same SoC which also used 64k pages was based on Debian (Etch?), and that Debian could be chrooted on the NAS5xx. The successor couldn't. Somewhere in a forum someone told my why that was (compiler/linker flags which changed between the 2 releases) but unfortunately that forum is gone.
So odds are that the OpenWrt 4k userland also cannot run on a 64k kernel. But if you still have stock firmware, you could try to chroot the OpenWrt userland.
About samba performance, if you search the Doozan forum you'll find that many people complain about the difference in speed between stock and, in this case, Debian. In this forum you can find the same problems. Apart from some throughput decrease from SMB1 to newer protocols, I believe that in stock sometimes shortcut were made, based on an assumption of the usage, to speed up the throughput on cost of some stability. I know of at least two NASses (a Medion based on an Oxnas chip, and a ZyXEL based on a Marvell Armada chip) where you could corrupt your filesystem by using it outside that assumption space. In case of the Medion you only needed to use a too new client, in case of the ZyXEL large files (>2TB, or something like that)
64k page is PPC magic Mindspeed Comcerto 2000 is ARM and probably less affected. Also network test can be performed using FTP protocol that is less CPU demanding @Jens
CONFIG_PAGE_SIZE* config is generic for all architectures and set in target/linux/generic/config-5.15
but then You need custom kernel build and some tests