Re: disk geometry (i386/amd64)

[Don NetBSD <netbsd-embedded%gmx.com@localhost>]

On 9/10/2018 11:33 AM, Mike Pumford wrote:
> On 10/09/2018 01:49, Don NetBSD wrote:
> > I'm not concerned with automatically detecting insertion/removal; that's
> > the job that the operator performs (above) -- along with the tagging of
> > the media, etc.
>
> I've done a lot of work with SAS disk enclosures that support SES. They often 
> have an SES command that can turn off the drive in a bay prior to removal (but 
> support is optional).

Aren't standards *wonderful*?  What value to "optional" if folks can elect to
NOT implement??  <frown>

My read of the SATA spec indicated that hot plugging was part of the SATA
standard (and, by extension, SAS).  But, that support for it on HBA's was
(ahem) "optional".  In particular, support for cold presence detect (but, I'm
relying on the operator to perform that function as HE will be the person
doing the plugging/unplugging!)

[None of the products involved allow the drive to be removed so this wasn't
an issue for the design]

OTOH, when trying to repurpose someone ELSE's hardware, those details get
to be important (and, often hard to discern, reliably!)

> > But, I'd be concerned about pulling a drive that was still *spinning*.
> > atactl(8) doesn't seem to work with sd(4) devices.  I'll have to see if
> > drvctl -d spins the drive down as it is disconnected (and maybe a timeout
> > to ensure the operator doesn't remove the drive before its had a chance
> > to spin down sufficiently)
>
> A SCSI stop unit command may spin down a SAS disk but its not guaranteed as it 
> depends on whether or not the SAS HBA or expander is sending the drive periodic 
> NOTIFY primitives (which trigger drive spinup). What works with one SAS HBA may 
> not work with a different one.
>
> On a more practical note. As long as you disconnect the drive from the 
> connector gently and give it 5-10 seconds to spin down before any significant 
> movement SAS/SATA drives tend to survive removal even if they are spinning.

As with most enterprises, I'm having to deal with nontechnical "political"
issues, here.

I'd first suggested using existing product (with a firmware update) to perform
these tasks.  The advantages being:
- we have a virtually unlimited number of them ("build more")
- they use much less power per spindle than a repurposed server
- they can be scaled to process tens or even hundreds of concurrent drives
- eliminate all the noisey fans
- we know EVERYTHING about what's in the box (hardware & firmware)
- I can dumb-down the requirements for the operator (so he doesn't damage
  a test fixture *or* components that will be used in saleable product!)

But, some bright-eyed dweeb uttered "Why not use an old server and write
something in Linux to do the job?!" -- because, to said dweeb, Linux is the
panacea for all problems technical (ignorance must be a wonderful state of
mind -- everything is "easy-peasy"!)

So, *his* "solution" fell into my lap to implement.  Having no taste for Linux
(running NetBSD since 0.8), I picked a more familiar platform.  I'd like to
make a "legitimate" effort to make it work.  But, note that the more stuff
that I rely on in the design (e.g., the hot-pluggable HBA), the more
restricted the choice of repurposable hardware available:
    "Why can't we make another one of these fixtures?  We've got several
    other old servers in the scrap pile..."
I don't want to have to explain how all servers are not created equally.

[Ideally, I'd like to throw it back into *his* lap and watch him struggle
to "solve" the problem -- and separately, pursue a parallel approach of
repurposing our existing product (hardware & software) to be available
when he's publicly learned his lesson (Linux is NOT a panacea).  But,
that would be too petty.  Given time, he'll learn that solutions are
rarely as simple as they seem!]

> In SAS hotplug is not optional. ALL SAS HBAs should support it regardless of 
> whether the drive is directly plugged in or in some of drive carrier. I don't 
> know if NetBSD will deal with these events though.

I'm using a Dell 2950 as a first pass.  The drive sleds don't add anything
to the mix -- the HBA can accept SATA drives as well (but no mix-n-match).
The SATA->SAS converters that would be used in a normal deployment can be
removed as they would just complicate the job performed by the "operator".

The "support" question is then one of whether NetBSD can issue the correct
commands to the drive to prepare it for removal (and make it ready after
insertion).  Without the hot plug capability, the operator would have to
wait for all drives to be processed and then power down the server to replace
the drives with the next set.  And, how much information I can extract from
the native drive (e.g., serial number, model, etc.)

[This is how I'd support changing drives using our own hardware -- but, we
could afford to power down ONE drive/system at a time and not impact N
other drives that happen to be sharing that repurposed server]