5 hours ago
(This post was last modified: 5 hours ago by Dendrocalamus64.)
I have this installed & running now. That sure took longer than I expected it to.
The Hardkernel 256GB emmc has some sort of an orange bump on the bottom, opposite the socket, that the Pine64 64GB emmc which it replaced did not.
There was a sticky pad on the PBP mainboard underneath the emmc to help keep it in place while it's being bumped around; I had to scrape it off with a spudger to get the 256 installed. The new emmc still doesn't sit quite level, it angles up slightly due to the bump; I hope it isn't going to come loose.
Using the Pine-branded emmc-to-USB adapter which I got from the Pine store several years ago, the 256 GB emmc consistently gave read errors whenever it was being accessed raw, which greatly slowed down operations like mounting & partitioning. It's not doing that in the emmc slot, and the 64 isn't doing that on the adapter. For example, this sort of command would trigger a read error if it wasn't read from cache, but reading from a filesystem would not:
$ sudo dd if=/dev/sda count=20480 | md5sum
The errors were recoverable and only showed up in dmesg & syslog, but made it slow.
I wanted to partition the new storage myself and rsync over my files, instead of reinstalling. Things I learned in the process:
- gpt's partition table & backup partition table occupy the first 64 and last 64 sectors of the main address space of the medium; thats why the skip=64 when writing bootloaders.
- The emmc boot partitions (mmcblk2boot0 and mmcblk2boot1) are NOT being used. The convention is to leave the first 30 MiB in the main address space unallocated so there's space for bootloaders and start the first partition at 62500 sectors; with alignment to 2048 sectors as parted recommends, the first partition starts at 32*2048 = 65536 sectors.
- Stock uboot can only boot from FAT filesystems. Using ext4 for your /boot partition makes the medium unbootable. I only tested that FAT16 works.
- If you want the root partition on lvm, as I did, you need to rebuild the initramfs with the lvm2 hook included (instructions) and specify the root fs as e.g. root=/dev/VG1/LV1. u-boot doesn't understand lvm by itself; the tools in the initramfs are needed to mount it.
- Boot order is supposed to be USB > SD > eMMC but with the particular boot loader versions I was using, the USB wouldn't boot at all without the internal emmc disabled. Failure to boot off the USB adapter doesn't necessarily mean it won't boot when slotted.
- The last revision of tow-boot before the maintainer bailed doesn't work on my PBP so it's u-boot only.
In principle, lvm should be a great fit for an all-solid state system like the PBP. Logically contiguous blocks on the medium aren't physically contiguous, so a partition table designed for rotating disks that forces you to keep partitions completely contiguous rather than just reasonably unfragmented, as allocation in extents is intended to do, doesn't make sense.
But what about in practice? I had a hard time finding any performance numbers for lvm other than "works for me", some synthetic benchmarks, and an ancient study using lvm1 which found that performance with small files was terrible.
Life on arm means compiling a lot. I don't want it to slow down big builds.
I've been benchmarking by building haveno's git repository, which is a convenient size. It goes from 260M to 5.1G over the course of a build, and takes about 7-10 minutes to do it. 98% Java code, build managed with Gradle.
Testing `make skip-tests` starting with all dependencies resolved & cached on disk, a gradle daemon running, parallel builds enabled & build caching off, and the linux disk cache freshly flushed, it took about 7m 20s to build on the old emmc without lvm, and 7m 3s on the new emmc with lvm2. Still to test is building on the new emmc in the non-lvm partition I left for comparison, and building from heavily fragmented logical volumes.
The Hardkernel 256GB emmc has some sort of an orange bump on the bottom, opposite the socket, that the Pine64 64GB emmc which it replaced did not.
There was a sticky pad on the PBP mainboard underneath the emmc to help keep it in place while it's being bumped around; I had to scrape it off with a spudger to get the 256 installed. The new emmc still doesn't sit quite level, it angles up slightly due to the bump; I hope it isn't going to come loose.
Using the Pine-branded emmc-to-USB adapter which I got from the Pine store several years ago, the 256 GB emmc consistently gave read errors whenever it was being accessed raw, which greatly slowed down operations like mounting & partitioning. It's not doing that in the emmc slot, and the 64 isn't doing that on the adapter. For example, this sort of command would trigger a read error if it wasn't read from cache, but reading from a filesystem would not:
$ sudo dd if=/dev/sda count=20480 | md5sum
The errors were recoverable and only showed up in dmesg & syslog, but made it slow.
I wanted to partition the new storage myself and rsync over my files, instead of reinstalling. Things I learned in the process:
- gpt's partition table & backup partition table occupy the first 64 and last 64 sectors of the main address space of the medium; thats why the skip=64 when writing bootloaders.
- The emmc boot partitions (mmcblk2boot0 and mmcblk2boot1) are NOT being used. The convention is to leave the first 30 MiB in the main address space unallocated so there's space for bootloaders and start the first partition at 62500 sectors; with alignment to 2048 sectors as parted recommends, the first partition starts at 32*2048 = 65536 sectors.
- Stock uboot can only boot from FAT filesystems. Using ext4 for your /boot partition makes the medium unbootable. I only tested that FAT16 works.
- If you want the root partition on lvm, as I did, you need to rebuild the initramfs with the lvm2 hook included (instructions) and specify the root fs as e.g. root=/dev/VG1/LV1. u-boot doesn't understand lvm by itself; the tools in the initramfs are needed to mount it.
- Boot order is supposed to be USB > SD > eMMC but with the particular boot loader versions I was using, the USB wouldn't boot at all without the internal emmc disabled. Failure to boot off the USB adapter doesn't necessarily mean it won't boot when slotted.
- The last revision of tow-boot before the maintainer bailed doesn't work on my PBP so it's u-boot only.
In principle, lvm should be a great fit for an all-solid state system like the PBP. Logically contiguous blocks on the medium aren't physically contiguous, so a partition table designed for rotating disks that forces you to keep partitions completely contiguous rather than just reasonably unfragmented, as allocation in extents is intended to do, doesn't make sense.
But what about in practice? I had a hard time finding any performance numbers for lvm other than "works for me", some synthetic benchmarks, and an ancient study using lvm1 which found that performance with small files was terrible.
Life on arm means compiling a lot. I don't want it to slow down big builds.
I've been benchmarking by building haveno's git repository, which is a convenient size. It goes from 260M to 5.1G over the course of a build, and takes about 7-10 minutes to do it. 98% Java code, build managed with Gradle.
Testing `make skip-tests` starting with all dependencies resolved & cached on disk, a gradle daemon running, parallel builds enabled & build caching off, and the linux disk cache freshly flushed, it took about 7m 20s to build on the old emmc without lvm, and 7m 3s on the new emmc with lvm2. Still to test is building on the new emmc in the non-lvm partition I left for comparison, and building from heavily fragmented logical volumes.
