Date: Tue, 11 Sep 2018 00:19:57 -0700
From: Don NetBSD <netbsd-embed...@gmx.com>
Message-ID: <3cedac34-90d8-78ff-b320-de2c5ac8c...@gmx.com>
| [should I be "reply all" or just the list? I guess a matter of personal
| preferences?]
It usually makes little difference - it certainly makes no difference to me.
People who get annoyed by receiving 2 copies, usually ask to be
excluded.
> | > The raw partition allows this.
> | Again, as long as nothing else tinkers with the in-kernel copy of the
> disklabel
> | before I look at it.
>
> No, regardless of that.
| Please reread the initial exchange (reproduced below, for convenience):
I know what you mean, you're just missing the point. From the raw
partition you can discover everything that you need. The label is
irrelevant for your use, ignore it. You can use the new ioctl if it
works to get info from the drive, if not, you just do it the hard way.
First, find the sector size - start reading (from the raw device, obviously)
from sector size 128 (or 256, or 512, or whatever you think a suitable
minimum is) in increasing powers of two until it works. The driver cannot
let you read less than a sector, it has no way to tell the drive to stop
sending data half way through, and no place to put the data but your
buffer, so if the buffer is smaller than a sector, it must fail (very quickly).
If your drives might have been formatted on one of those bizarre
systems that allows non power of 2 sized sectors, then you the only thing
supported might be the "format" ioctl (and a LONG period of waiting).
I doubt NetBSD supports unconventional sector sizes at all.
Second, do a binary search over the plausible size range reading
single sectors (now you know their size), when you get an error,
you have exceeded the capacity of the drive (or the drive has bad
sectors - the error value should reveal which it is). If you get data,
(including an EIO from a bad read) you need to go upwards half way,
if an error (EINVAL or whatever it turns out to be), down.
| Again, as long as nothing else tinkers with the in-kernel copy of the
disklabel
| before I look at it.
Just don't look at it at all.
However, your "as long as nothing else tinkers" seems a peculiar worry
given the application you seem to have in mind. What "something else"
could possibly be doing the tinkering in the environment you are describing?
| In the absence of
| other mechanisms (e.g., the DIOCGDISKINFO ioctl), my only way to determine
| the actual size of the medium would be to explore the 'd' partition with
| seeks to ever increasing offsets.
Yes, exactly. 48 block reads should handle a binary search over any
plausible drive size I'd think (somewhere in the ZB range I think that covers,
assuming 512 byte sectors, bigger with bigger sectors), which should take
all of a second on any rational system (and recall when you're out of range,
the driver will error, without actually performing an I/O, so that's fast).
Plus the extra half dozen to find the sector size.
| My goal is a reliable way of exposing what the "disk, itself" says!
Yes, I think we understand that. Once again, ignore the label. It
is useless for big drives anyway (it is capped at 2^32 -1 sectors.)
(or maybe half that, I forget if it thinks it is signed.)
| (which appears to be DIOCGDISKINFO, but not DIOCGDINFO)
Probably, yes. If that (DIOCGDISKINFO) works, great, if not,
it is all still possible.
| Ah, OK. So, if I verify this for the sd(4) driver on a particular OS
| version/port, then I need never concern myself that some particular *drive*
| may fail to yield valid data? I.e., if the ioctl fails, I can panic()?
You could, but that would not be my recommended action. Certainly
drives have made their size available to the driver ever since we started
getting intelligent drives, I very much doubt you could find one still working
which did not support that - anywhere. But is dealing with that case
so hard, compared with all else you are doing, that a panic is acceptable?
(Even given you just mean an application panic, as in "discard the drive
in slot 23" and not "crash the kernel")
| > SMART [...] so it is clearly possible.
|
| I think only via wd(4)?
Oh, you mean, not sd(4) - yes, possibly. Sorry, I have no idea how
one would access that kind of data over scsi.
kre
