Re: In-kernel units for block numbers, etc ...

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 28 Nov 2015 14:57:08 +0000 (UTC)
    From:        mlelstv%serpens.de@localhost (Michael van Elst)
    Message-ID:  <n3cfc4$2pm$1%serpens.de@localhost>

  | I've just committed a few fixes for disks with non-512byte sectors
  | to HEAD.
  | 
  | cgd now works on my drive with 1k sectors.

Thanks, works for me too (I didn't have all the changes you made to cgd.c
and certainly not all of the ones to the other files, though I had been
looking in that region).

It works for my 4K sector drive now too ... at least, provided that it
is configured as cgd0

When it is cgd1, I get a panic ... that I think is from the same underlying
cause as PR 41704 (from July 2009...)

This is (it appears) caused by this line in cgdioctl() ...

        dk_getdisklabel(dksc, 0 /* XXX ? (cause of PR 41704) */);

The 0 ((dev_t)0) and XXX have been there since cgd.c 1.1, so this
is nothing new!

Whether it is because of the secsize changes, or whether it would always
have caused a panic (I config'd cgd1 without bothering with cgd0 .. my
convention is that cgd0 is always a (fairly small) filesystem that contains
stuff like my ssh private keys ... I didn't have that on the test system
I was using, no point .. but I still did cgdconfig cgd1 ... just from
habit.)    When I switched to use cgd0 it worked.

The panic traceback was ...

vpanic() at vpanic+0x140
snprintf() at snprintf
startlwp() at startlwp
calltrap() at calltrap+0x19
disk_read_sectors() at disk_read_sectors+0x47
read_sector() at read_sector+0x1d
scan_mbr() at scan_mbr+0x32
readdisklabel() at readdisklabel+0x150
dk_getdisklabel() at dk_getdisklabel+0xbf
cgdioctl() at cgdioctl+0x76c
cdev_ioctl() at cdev_ioctl+0x90
VOP_IOCTL() at VOP_IOCTL+0x3b
vn_ioctl() at vn_ioctl+0xa6
sys_ioctl() at sys_ioctl+0x17e
syscall() at syscall+0x9c
--- syscall (number 54) ---

which is about as blatant a clue that you can get that this is the problem.
(That is not the panic I was seeing in my earlier testing, but I might have
been using cgd0 to test earlier, that was a couple of months ago now, and
I don't remember...)

So, I think it is finally time to figure out how to fix PR 41704 once and
for all - I doubt it is worth worrying about why I got a panic, and the PR
reports just getting EINVAL, and often, even for cgd1... things seem to
work fine (normally with cgd0 config'd before cgd1 of course.)

But since this has been there, complete with its XXX, since 2002 when
cgd was committed, it obviously isn't going to be easy to fix.

Somehow, we need to get the dev_t for the device passed down, or stored
somewhere.   Currently that info seems to be missing.

Anyone have any suggestions?

kre