Re: New Optane AIC does not show up in FreeBSD until . . . ?

From: Mark Millard <marklmi_at_yahoo.com>
Date: Tue, 16 Feb 2021 03:43:53 -0800
On 2021-Feb-16, at 02:22, Harry Schmalzbauer <freebsd at omnilan.de> wrote:

> Am 16.02.2021 um 11:08 schrieb Mark Millard:
>> On 2021-Feb-16, at 00:48, Harry Schmalzbauer <freebsd_at_omnilan.de> wrote:
>>> Am 14.02.2021 um 02:36 schrieb Mark Millard via freebsd-current:
>>>> On 2021-Feb-13, at 16:40, Warner Losh <imp at bsdimp.com> wrote:
>>>> 
>>>>> Are you aware of gpart create?
>>>>> 
>>>>> Warner
>>>> From which I derive that I had an implicit, incorrect
>>>> assumption that gpart show would in some way list
>>>> everything available that gpart could manipulate
>>>> (including for use in creation).
>>> 
>>> 'geom disk status' is my first choice for such a case.
>>> Even nvd(4) should show up I think, nda(4) just changes the access path, not geom(8) integration, afaik.
> 
> ...
>> Thanks for the alternatives to sysctl kern.disks
>> and to nvmecontrol devlist for making a list to
>> compare to gpart show output in order to find
>> what gpart show does not list (but can manipulate).
> 
> gpart(8) doesn't enumerate disks without any supported partition scheme present.
> You can create new partition schemes with the help of gpart(8), but it's imho correct not to show them, because 'gpart show' is meant to give information about (existing) partition schemes - no scheme no info; thus your vanilla disk is "unknown" to gpart(8).
> 
> I remember that I always thought the geom(8) disk class is kind of hidden - especially since the man page misses listing DISK in the
> "Currently available classes which are aware of geom(8)" section!
> 
> The "show" command was enriched to contain valuable details, such as NAA.
> So 'geom disk' turned into one of the most useful mass storage admin commands. imho.
> Maybe somebody should correct the aforementioned man page section and add add any hint in the SEE ALSO section, because there is no gdisk(8) aequivalent, like for all other geom classes...
> 
> -harry
> 
> P.S. Put it on my loger-term todo to file a bug report with a proposed man page diff...

Looks like "geom -t" output avoids me having to compare
two outputs to find mismatches in the list of names: its
output is sufficient to identify the name(s) for drives
that do not have the scheme information (and the names
of those that do). This at least helps cut down what I
have to coordinate, especially when only one device is
in question.

For example, ada2 in the below has only DISK and one DEV
line, not multiple DEV's, no PART line, nor other such:

. . .
ada0                                       DISK       ada0
  ada0                                     PART       ada0s1
    ada0s1                                 DEV       
  ada0                                     PART       ada0s2
    ada0s2                                 DEV       
  ada0                                     DEV       
ada1                                       DISK       ada1
  ada1                                     PART       ada1p1
    ada1p1                                 DEV       
  ada1                                     DEV       
ada2                                       DISK       ada2
  ada2                                     DEV       
da0                                        DISK       da0
  da0                                      PART       da0p1
    da0p1                                  DEV       
  da0                                      PART       da0p2
    da0p2                                  LABEL      ntfs/VirtMachs
      ntfs/VirtMachs                       DEV       
    da0p2                                  DEV       
  da0                                      DEV       
. . .

So I can infer that I need a gpart create on ada2 .
(Presumes I know from the naming that the device
is not analogous to a cd-drive with no media in
the drive.) The output does span the nvd* devices.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Received on Tue Feb 16 2021 - 10:44:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC