I’ve noticed on my system that building packages is very much I/O bound rather than CPU limited. So in an effort to try and speed things up I decided to install a cheap SSD as a system disk. While doing that I noticed some things and I wonder if they point to problems in NetBSD. I am using GPT partitions, so some of what I’m seeing is probably related to how wedges are installed, used and processed.
I use a home-brew script to install the NetBSD system, make my local changes in /etc and install a selected set of packages. So sysinst isn’t an issue for me here. In my script I destroy any existing GPT partitions on the target disk, zero out the first couple of disk blocks and then create new GPT partitions. After creation I newts them and mount them so I can load NetBSD from the tar files. I’ve been doing this for some time on spinning disks without any problems, but as soon as I tried to target the SSD I run into interesting issues. *) GPT and DKCTL merrily allow me to create wedges that can’t be mapped because the /dev nodes don’t exist. There aren’t any warnings or errors in the process, but trying to use them later in newts or mount commands does produces some strange errors. Not sure if this is a problem or not, just a bit confusing. Wedges appear to be created in ascending numerical order with lower numbered slots used first, but wiping the GPT header doesn’t seem to always immediately free the corresponding wedges. So after destroying the GPT header I used DKCTL to (re)make the wedges. This removes the old wedges. I do this after creating my new wedges too. *) The SSD is so fast that after creating wedges and even listing them, I find I can’t newts them until the buffers get flushed which dkctl does with the synccache command. This also happens after completing the newts operation; the newly formatted wedge can’t be mounted until the disk cache is flushed. This seems to be a possible file system buffering problem - if there are dirty disk buffers in memory created by gpt/dkctl and newts, why doesn’t the system access them instead of reading them from disk when doing the newts process? (At least that’s what I assume is happening based on what I’m seeing.) Is this an error? *) GPT and DKCTL happily allow me to destroy, recreate (or mis-create) wedges on disk(s) with wedges that are currently mounted in the running system. (Well it was running up to the point I did this.) I would think this is maybe something the system should at least issue a warning about, so is this a bug? *) I had been using the “name=“ parameter in both newts and mount with the wedges. This worked fine for spinning disks, but I see all sorts of random failures when the wedges are on SSD. Maybe this is related to a disk block buffering issue, not sure. My workaround is to figure out which DKn wedge corresponds to the name using dkctl, and specify the wedge by /dev/dk? for newts and mount. So, is any of what I’m seeing a real issue that requires a PR? Oh, this is running on NetBSD 8.0_STABLE on amd64. All my filesystem are FFS V2.
