I think he meant data loss? Both HDDs partition layouts need to be compatible in order to write one partition to the other HDD. So the user has to manually install the OpenWrt image on both. That said, on the duo it should be possible to install the openwrt-18.06 and -master images on either HDD. So switching between devel and stable is just one quick hdd swap away.
(By the way, does anybody know if hot-plugging is supported on the duo's secondary hdd?)
Hard to explain in a few words: What I mean is that the secondary disk, even if it contains OpenWrt, even if it contains the same Version of OpenWrt, doesn't necessarily have to contain OpenWrt that is configured for the Duo. Or this Duo. Painting over the installed version on the secondary drive may not be desirable.
I do. It is.
Sorry for slightly hijacking the thread but how are you supposed to do a raw install of OpenWrt using master since the image layout changed?
dd the factory image?
I think this thread left the "on-topic" rail a while ago.... and it will derail further until thomas closes it.... like the last one 
.
What image layout change are you talking about? The 256 MiB rootfs change back in 2016?
yeah pretty much. The images are .gzipped though, so you either need to unpack them, or you could also try zcat [if it's available - it should; given that the vendor uses Debian):
# zcat path/to/openwrt-apm821xx-sata-wd_mybooklive-[squashfs|ext4]-factory.img.gz > /dev/sda
The great thing about the lack of a useable NOR/NAND on the MBL is that you are basically required to have a HDD installed in order to use it. So you can download, unpack and dd the whole image to the HDD.
Even if it's 256MiB+ unpacked.
Thanks!
I got a bit confused since the rootfs image disappeared =)
https://downloads.openwrt.org/releases/18.06.0/targets/apm821xx/sata/
Seems pretty stable too, btrfs and Samba isn't very fast however (~19mbyte/s) but givent he hardware is still pretty nice. I also played around with ffmpeg a bit, shame that it can't use assembly (lack of altivec) and other optimizations but still performs good enough for light usage.
One bug(?) I've noticed is that it doesn't seem to be a safe way of turning it off. poweroff makes it reboots and halt does the same. Pulling the plug a few secs once the HDD has spun down seems to be ok (at least fsck etc doesn't complain) but it's not ideal.
You may be able to get better performance by increasing the MTU to 4500 (or 9000 - if supported) on your client and the MBL. At least that's what the WD Community does to "increase the performance"... (as well as killing all the firewall rules.)
Yea, the watchdog brings the device back from the poweroff. And unfortunately, the booke-wdt can't be disabled once it was set (no way out). But there's a script for that: softoff
It piggybacks on the sysupgrade mechanism. But instead of updating, the device gets left in a unresponsive mode were the hdd, leds and ethernet are turned off...
As far as performance goes I think it boils down to the CPU, I see ~4+ load so it's more than likely a hardware limitation.
Thanks for the information regarding the power down issue!
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)
(Would be nice to hear more performance numbers.)
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.
Yes, Let's hope so 
.
(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.
As configuration goes,
-O2 instead of -Os by default (https://github.com/diizzyy/openwrt/commit/648711831477cf624c4d58e91a064de302e4813d), musl 1.1.20-pre ie your patch (https://github.com/diizzyy/openwrt/commit/99bee9e9de5360e070b29f6281922ea07cbce0e2) and musl default opt (https://github.com/diizzyy/openwrt/commit/9bd3cafe3762db05affcc5cb978e9f23b0c8713a)
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.
Yeah, it's the crc32c of btrfs. I formatted my test MBL with btrfs and started a samba transfer and perf.
# perf top
PerfTop: 4533 irqs/sec kernel:82.6% exact: 0.0% [4000Hz cpu-clock], (all, 1 CPU)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
26.60% [kernel] [k] __crc32c_le
10.85% [kernel] [k] __copy_tofrom_user
2.78% [kernel] [k] cpm_idle
2.74% [kernel] [k] __softirqentry_text_start
1.03% [kernel] [k] emac_poll_rx
0.92% [kernel] [k] ata_scsi_queuecmd
0.85% [kernel] [k] tcp_rcv_established
0.62% [kernel] [k] __kmalloc_track_caller
0.60% [ip_tables] [k] ipt_do_table
0.59% [kernel] [k] __netif_receive_skb_core
0.52% [kernel] [k] __wake_up_common_lock
0.51% [kernel] [k] finish_task_switch
0.45% [kernel] [k] kmem_cache_alloc
[...]
Oops, it's 'option type bridge' and not option proto bridge'
# uci delete network.lan.type
# uci commit
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.
yeah, this is exhausting.
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.
btrfs? It'll hardly help as CRC32c eats up most of the CPU time...