Re: /dev/sdN -> /dev/sdN[cd] (was: port-amd64/51216: Can't create wedges on a large (3TB) disk, gpt is ok but dkctl gives an error message)

[David Brownlee <abs%absd.org@localhost>]

On 7 June 2016 at 10:00, Robert Elz <kre%munnari.oz.au@localhost> wrote:
>     Date:        Mon, 6 Jun 2016 18:35:43 +0200
>     From:        Edgar =?iso-8859-1?B?RnXf?= <ef%math.uni-bonn.de@localhost>
>     Message-ID:  <20160606163542.GR5700%trav.math.uni-bonn.de@localhost>
>
>   | > ie /dev/wd1 is a link to /dev/wd1d on i386 (etc) or /dev/wd1c (on sparc etc)
>   | YES.
>
> I offer attached alternate patches, the first makes /dev/wd0 as a chrdev
> and the second as a link.
>
> I do not have all the various architectures that have the various different
> strategies for naming and minor-numbering disk devices to test this thoroughly
> though, but what I have tested seems to work, and the changes (both versions)
> are so simple they seem unlikely to fail (and if they do, the effect would
> just be that the new nodes would not be correct, all the ones we're used to
> having would be fine, so simply removing the bogus ones would return the
> universe to its current state.)
>
> I prefer the chrdev version ... it is robust against removal of the ?dNx
> node names, which (sometime later, after tools/scripts have been adapted
> not to seek out the ?dN[cd] device names explicitly) might be something to
> do on a system using GPT and wedges (or even disklabel wedge autodiscovery).
> It also will provoke any lingering bugs if anything is currently relying on
> vnode locking for device exclusivity (with two different vnodes for the same
> underlying device).    But either version should work (only one of them
> of course!)
>
> Either version consumes 2 more names, and inodes, per disk device configured.
>
> Opinions?

Also would prefer the chrdev version. We probably want to ensure these
are added to install media as well (which may push some of them over a
current inode limit but that is much less of a tweak than the ongoing
kernel growth :)