Kernel 4.9.x has 64KB page size, while 4.19.x has 16KB page size (for now) due to a defect in the kernel which I have not fixed yet. Hence, you need to re-initialize swap space to match the new page size.
mkswap /dev/sda2
Sorry for the confusion and time lost. I will make sure to update the readme’s on the GitHub.
You are free to test btrfs and XFS, can’t see why they would not work I have been tracking the performance of these file systems, but so far concluded that for our older HW and mostly SATA drives, EXT4 delivers the best overall and, above all, consistent/predictable performance. Also, you can read your EXT4 drive on Linux/Windows in case something goes wrong.
Take a look here. XFS and F2FS are becoming solid alternatives, but btrfs not there yet IMHO for general purpose use.
My bigger worry though is that more recent versions of Linux seem to waste more CPU cycles in low level code like block/BIO drivers which are used by all file systems. Lots of constructs with x calling _x, calling __x etc, often not inlined and sometimes at each level the parameters are being validated again or a BUG statement is inserted.
On a quad core Intel/AMD that is no big deal, but on older HW this can be quite costly.
High performance kernel 4.19.29 for evaluation:here
As promised, an attempt to fine tune the performance of kernel 4.19 and port some tuning work from earlier versions to 4.19. This kernel has not gone through full torture test, nor is it available in source/patch format (yet). The goal is to get some feedback of whether any of you are seeing improved results and good stability.
Compared to standard OpenWRT kernel, this kernel should deliver ~70% performance increase on Samba write (~80 MB/s sustained) and 20% on Samba read (~112 MB/s read). It should give around 5 to 10% improvement over 4.19.24.
The biggest issue is that I’m unable to achieve the 170MB/s file system read that 2.6.32.70 was giving me on the same drive, not with the dwc_460ex driver, nor with the sata_dwc_nqc driver. Somewhere ATA/SCSI code has slowed down, but I can’t seem to find where.
Unfortunately, there is limited “perf” tracing support for ppc_4xx hardware in the kernel, despite good HW support for PMU and tracing. Maybe write a performance counter driver… Not easy with just net console…
High performance kernel 4.19.33 with patch set to compile your own kernel :here.
Samba read improved to 115MB/s and writes at 82 MB/s. Patches updated for 4.19.34 validated, but it’s a bit slower due to some code changes.
First builds of 4.20 look promising, lots of kernel cleanup and some tests run 20% faster.
i am following Schwabenlan.de guide to update my WDL but i am stuck at “debootstrap --arch powerpc jessie /newsys/ Index of /debian
/usr/share/debootstrap/functions: line 1591: cannot create temp file for here-document: No space left on device” can someone help me?
@Ewald,
Is it possible to compile version 2.6.32 kernel source from RHEL with patch for WD MBL? RHEL Source
I think that this version contains backported patches and should be more safe. Is this correct?
@majorshock, haven’t done the full install for a long time but never saw this error. An additional challenge is that Debian Jessie is no longer supported on PowerPC 32. Install from scratch is a long and painful process and leaves you with an unpatched version since Debian shut down the security patches depot. Then you will have to struggle through dependency nightmare to e.g install GCC 8.3 or 7.4 if you want to compile a kernel. That is why I made a pre-patched Debian 8.11 available on the github page ( My-Book-Live/debian/debian 8 (Jessie) at master · ewaldc/My-Book-Live · GitHub)
@Joosten,
Not sure I fully understand the question… Yes, given the proper PowerPC 32 cross compiler and version (e.g. 7.4 or 8.3) you can take the official 2.6.32.71 kernel source, apply the patch set posted on my github and cross compile a kernel. Running RHEL on my book live is a quite another challenge, which is not worth the effort IMHO. Hopefully that answers your question.
Thanks formulier your answer! You understood me correct! So you think it must possible to cross compile the kernel. Do you think there is any advantage in doning this? An perhaps also for the 4.1 kernel?
@Joosten,
No run-time performance advantage in cross compiling as you are using the same gcc compiler (e.g. 7.4 or 8.3). Massive difference in compile time though. On a 16-core Intel CPU and NVRAM drive I was able to do a full build in under 12 seconds (make -j 24) ! It easily takes 2 hours on the MBL, … if it even finishes the build. I had to debug the gcc linker for 7.4 since it kept crashing with Out of Memory error or getting killed by OOM Killer. I have posted a section on cross compiling. Practically I only build loadable kernel modules locally on the MBL. Those complete in just a few seconds with no need to relink the kernel.
If you can share your experience on compiling on RHEL, I am happy to add your installation steps to the README on GitHub. So far I only used/documented Debian/Ubuntu/Linux Mint.
Hope this helps.
Glad to see great work have been done to this little machine. Debian still has powperpc port available with very updated packages. You can make clean installation with debootstrap, the problem and quirk is mentioned here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927255
Latest qualified kernels: 4.9.169 and 4.19.44 on github.
Patches updated for 4.19.44. Stress tests for these kernels are currently in progress. Open issues: disk activity led for 4.19 kernels
ok, I guessed it, no I am “in” (via ssh) my jessie running on my old MBL.
But what I have todo next ?
I would like to use the 2TB data drive as a samba server.