Is this samba write or read performance (or both?). I know that the MBL single can do sustained writes at 23 MiB/s and sustained read at 46 MiB/s to/from a samba4 share on a standard ext4 partition. (Of course, this implies some changes to the config. (removing "option proto 'bridge'" from /etc/config/network 's lan config, stopping & disabling all unneeded services: firewall, dnsmasq, odhcpd, ) and doing some optimizations on the clients (mount share via cifs and use SMB3)
I'm not sure I can explain what I'm thinking of... If you put different versions on each disk, then you have to manage the boot and root partitions very carefully, or you would produce even more problems by different kernel versions.
I mean the boot process looks like this: sata1:0 (boot) --> sata0:1 (root), so the partitions should be written crosswise. In this case the official upgrade process will definitely fail.
Ah, the sata1:0 and sata0:1 terminology is limited to u-boot, but doesn't apply to linux. To deciding factor currently is the "root=/dev/sda2" cmdline in the mbl-boot.scr script. And this is where it will/can get funky, since linux enumerates the disc in it's own way. The first fully detected disc gets to be /dev/sda, the second one /dev/sdb, etc. So even with the patch from @takimata it can still happen that if the sata 1:1 disk is slow to respond/initialize the sata 0:1 disk will win the race and get to be /dev/sda... And there's not much you can do, expect move away to PARTUUID / UUID.
I don't think that's an issue though. By the time OpenWrt boots, all available disks will have been thoroughly initialized, at least two times (at least once by on-flash boot script, at least once more by the on-disk boot script), and I've observed sata init thoroughly waiting even for slow disks before handing back control to the rest of the boot script.
(Though, the "respond/initialize" was poorly worded, it should have been just "respond". As Linux performs its own device discovery asynchronously. And sadly, it does not care that the HDD in sata 0 (if present) is supposed to be sda and likewise that the HDD in sata 1 is supposed to be sdb. )
Both read and write seems to be limited at around 20mbyte/s, top shows a lot of io load which is probably due to btrfs or possibly a wonky device driver.
Unneeded services disabled however option proto bridge is still on, I'm not very familiar with the UCI so if you could provide a template I'd be grateful.
SMB3 would probably help but most of the load is io and not really Samba-related.
Just as a heads-up: Right now I really don't have time and energy to fiddle around with git/github settings to maneuver around some red tape when submitting the patch for 18.06, so I withdrew the PR. If someone feels inclined to backport the patch (i.e., the incredibly complex task of swapping two zeroes and ones), feel free to do that.
A little known feature of git is that you can attribute the authorship of a commit by adding a (extra)
FROM: User <email@country.cc>
tag at the top of commit message. This is usually used, if the "messenger" isn't the author, but it can also be used to fix github's idea of the commit author.
Once again, I kindly ask @chunkeey or @takimata to check WD Community for the latest patches by Ewald with working NCQ. Link to Ewald's Google drive.
The most interesting patch is "mbl_sata". It has NCQ fixed driver inside. But it's for kernel 4.9.119.
I found some "go-faster stripes" in Netgear's "premium N" WNDAP620 GPL code for the ibm EMAC ethernet driver (TSO - tested on IPv4). I put it into the staging repository for anyone who wants to see close to 70MIB/s samba read performance with an ext4 fs .
Ooh, exciting. I have a mightily stupid question, though: Where is that staging repository? That would be the "staging" branch of your "apm82181-lede" repo?
I'm rather eager to try those improvements, in hopes that not only Samba but also rsync will speed up. I "backup" my data across a few drives and locations, and especially "cloning" a new 2 TB disk is no fun if rsync never goes beyond 20 MB/s.
No, I use ext4. I have actually never looked into why rsync never went beyond ~20 MB/s, and I cannot do it right now (on the other side of the world for the next ~2 months, and I only have one MBL with me). But it seemed to be a hard limit, even with compression and everything else disabled.
As I said, I did. No compression, not even checksum. Didn't make any significant difference, even between two MBLs connected on the same gigabit switch. I seem to remember that the MBL running the rsync daemon was hitting 100% CPU, but I'm not in the position to confirm that right now.
Hmm, if your are set on btrfs and the NAS and PC are connected via ethernet (WLAN will not really work here) and you don't mind the extra btrfs overhead on your PC, you could go via iSCSI. OpenWrt's Package library already has the tgt package. But currently it requires a custom image, since it needs CONFIG_KERNEL_AIO which isn't enabled by default.
So you could export the btrfs partition as a iSCSI target and let the beefier PC (as the iSCSI initiator) do the heavy filesystem operations on its own.
Sadly, TSO won't help you much there, as it offloads ethernet tcp tx so it is only interesting for cases where you copy stuff from the NAS to your PC. For the use-case you are looking for we'll need to dig up some variant of "LRO" for the emac.
I'm digging this up again since I just upgraded my MBL to 18.06.2 and again found the CPU hit 100% at ~19MB/s transfer rate (samba in this case, although the load is not in smbd itself). I looked into the commit history and as far as I can see the TSO patches are not in master, correct?
(Background: I'm not completely unfamiliar with building from source, but my track record is very much hit and miss, so I usually resort to the ImageBuilder for my slightly customized images.)
@HimuraCarter,
I have moved all MyBookLive patches to GitHub, no need to look at years of blog history . Please note that there is also a modified EMAC network driver that supports hardware TSO (checksum offloading), Interrupt Coalescing, SYSFS, Mask Carrier Extension signals, jumbo packets and more. With MTU-4088, it achieves 122MB/s over netcat and 117MB/s over samba (SMB3) read (Windows 10). To get the last 5Mb/s, I had to inline a few skb calls but no change to the code. Sorry about 4.14, but I am working on 4.19. Unfortunately 4.14 never survived the standard release test used which is around 96 hours of torture test. IMHO a must for a NAS that is hosting valuable data... Rsync is a different problem though... With Debian rsync, ~25MB/s for larger files (WBL NAS to WBL NAS). I once fixed rsync to do ~70MB/s between two WBL's, but I lost that code during a torture test that corrupted the whole drive and the user space crypto API code that went with it
@takimata,
the STA control patch was completely bogus and correctly revoked in 4.20 as the code already took care of newer and older HW. Hence it will be required to patch 4.19 for proper operation.
if (emac_has_feature(dev, EMAC_FTR_HAS_NEW_STACR))
r = EMACX_STACR_STAC_WRITE;
else
r = EMAC_STACR_STAC_WRITE ;
.
.