Re: Fun with SSD and GPT wedges

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Feb 11,  3:42pm, Robert Nestor wrote:
}
} 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

     I assume here that you mean "gpt remove ...".

} disk, zero out the first couple of disk blocks and then create

     Unless you know what you're doing, you should be using, "gpt
destroy".  The command is there for a reason.  One of the nice
things about GPTs is that there is a backup automatically created.
Zeroing out the first couple of disk blocks DOES NOT get rid of
the GPT.  This can be seen by using "gpt recover".

} new GPT partitions.  After creation I newts them and mount them

     Even though you have been consistently referring to a small
salamander, I'm assuming that you actually mean newfs(8).

} 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.

     There is absolutely no difference between a spinning disk and
an SSD as far as the OS is concerned.

} *) 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

     gpt(8) is a tool for manipulating on-disk structures, nothing
more.  It does do the equivalent of "dkctl makewedges" by issuing
the equivalent ioctl() after many operations.  dkctl(8) is a tool
that is mostly for interacting with the dk(4) device driver.

} 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

     Yes.

} to always immediately free the corresponding wedges.  So after

     Again, all gpt(8) does is manipulate on-disk data structures.
It doesn't know anything about wedges or anything else.

} 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 cant newts them until the buffers get flushed

     Are you using the raw device?

} 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

     There are no file systems involved until after a successful
mount(8).

} 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?

     It is highly likely that you are assuming incorrectly.

} *) GPT and DKCTL happily allow me to destroy, recreate (or
} mis-create) wedges on disk(s) with wedges that are currently

     Again, gpt(8) only manipulates on-disk data structures and
doesn't know anything wedges or the data contained within partitions.
dkctl(8), or rather dk(4), won't let you destroy an open dk(4),
which includes ones that are mounted.

} 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?

     dkctl(8) won't let you do anything to an open dk(4) and it is
out of scope for gpt(8).

} *) 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.
} 
}-- End of excerpt from Robert Nestor