12-20-2024, 02:34 PM
(This post was last modified: 12-20-2024, 02:44 PM by Dendrocalamus64.)
Second run on LVM, ext4: BUILD SUCCESSFUL in 7m 7s (427 s)
Non-LVM partition, same MMC, ext4: BUILD SUCCESSFUL in 6m 57s (417 s)
So lvm took 2.4% longer.
The old emmc might have been slower just because it was older. Flash is supposed to get slower as it wears.
The amount of writing that this build does is still concerning. I found one thread on serverfault where a comment said,
https://serverfault.com/questions/238033...nder-linux
And that is not my observation at all. I had 'watch -n5 iostat -h' running during the builds, and saw kB_wrtn go up by 5.8 G - 5.9 G, which is in line with the change in size of the directory. ext4's lifetime writes field is only updated on remount; since I had non-lvm on a separate partition, I could easily check it, and it showed +6 GB written, rounded to the GB.
What write amplification factor does the emmc multiply that by? There doesn't appear to be any way to know. Real SSDs support smart monitoring, which let you check NAND writes vs host writes. MMCs don't have any public interface to check that.
Short version, the PBP 2.0 should have a built-in M.2 slot so you don't have to try to cram an adapter in there, and it needs more RAM. The PineTab's SoC is supposed to support up to 32 GB RAM; with even 8 GB, you could do the build on a tmpfs and it would have enough left for the compiler to squeak through. With 16+ GB, it would be comfortable. Modern mega-projects like this show very clearly why 64 GB emmc & 4 GB RAM aren't enough if you want to do actual software development rather than just building packages occasionally for personal use. The PBP's processor is actually powerful enough to do the build in < 4 m with build caching enabled, but you shouldn't have to worry about how many build cycles you're doing per day. The .jar files are already compressed, so using zram to make a compressed tmpfs, while easy to set up, didn't help.
Non-LVM partition, same MMC, ext4: BUILD SUCCESSFUL in 6m 57s (417 s)
So lvm took 2.4% longer.
The old emmc might have been slower just because it was older. Flash is supposed to get slower as it wears.
The amount of writing that this build does is still concerning. I found one thread on serverfault where a comment said,
https://serverfault.com/questions/238033...nder-linux
Quote:"BEWARE: The ext4 lifetime_write_kbytes and session_write_kbytes are not representative of SSD memory cell writes. I've seen one system report 15TB for ext4 lifetime_write_kbytes, while the SSD itself reported only 1TB via SMART attribute 241. I suspect ext4 might be adding the entire size of the filesystem's free space to those statistics every time fstrim runs, even though the SSD controller obviously wouldn't repeatedly erase all those available blocks if they hadn't been touched since the last erase. tune2fs -l output appears to be similarly misleading."
And that is not my observation at all. I had 'watch -n5 iostat -h' running during the builds, and saw kB_wrtn go up by 5.8 G - 5.9 G, which is in line with the change in size of the directory. ext4's lifetime writes field is only updated on remount; since I had non-lvm on a separate partition, I could easily check it, and it showed +6 GB written, rounded to the GB.
What write amplification factor does the emmc multiply that by? There doesn't appear to be any way to know. Real SSDs support smart monitoring, which let you check NAND writes vs host writes. MMCs don't have any public interface to check that.
Short version, the PBP 2.0 should have a built-in M.2 slot so you don't have to try to cram an adapter in there, and it needs more RAM. The PineTab's SoC is supposed to support up to 32 GB RAM; with even 8 GB, you could do the build on a tmpfs and it would have enough left for the compiler to squeak through. With 16+ GB, it would be comfortable. Modern mega-projects like this show very clearly why 64 GB emmc & 4 GB RAM aren't enough if you want to do actual software development rather than just building packages occasionally for personal use. The PBP's processor is actually powerful enough to do the build in < 4 m with build caching enabled, but you shouldn't have to worry about how many build cycles you're doing per day. The .jar files are already compressed, so using zram to make a compressed tmpfs, while easy to set up, didn't help.
