Re: add disk size to "struct disk"?

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Le 27/04/12 18:43, Matthias Drochner a écrit :
> On Fri, 27 Apr 2012 01:02:46 +0200
> Jean-Yves Migeon<jeanyves.migeon%free.fr@localhost>  wrote:
> > Why push it to struct disk rather than letting backends handle it?
>
> As the code looks now, the functions which scan disklabels
> (sys/dev/dkwedge/dkwedge_*.c) get a "struct disk *". To get
> the actual size, it would need to open the device and call
> an ioctl. As I see it, the only ioctls available for now are
> disklabel related, thus limited to 32-bit sector numbers.
> So it would need a new ioctl.

Fair enough, it adds complexity for no real benefit.

> Or the disk size would have to be passed down the API
> (driver->dkwedge_discover()->dkwedge_discovery_method).
> There is also dkwedge_add() which can be called from
> userland dkctl(8). For useful checks, it should also get
> the total disk size. Atm, it fails to do even simple
> overflow and overlap checks, as you can see here:
>
> # dkctl sd0 listwedges
> /dev/rsd0d: 3 wedges:
> dk5: zzz, 2000 blocks at 500, type: ffs
> dk3: xxx, 1000 blocks at 1000, type: ffs
> dk4: yyy, 11529215046068469760 blocks at 8070450532247928832, type: ffs
>
> This code certainly needs some design work.

Design question: do you expect the checks to be performed in userland, 
so anyone can be free to have overlaps/overflows, or let the kernel do 
the checks and return errors using the size obtained through disk(9)?

> > Having total disk size in struct disk means you have to keep it in
> > sync some way or another (ie. callback maybe).
> > Resizing disks can be a common operation
>
> This would have to deal with open partitions or attached
> wedges on disks being shrunk. So perhaps a callback into
> the other direction, from the driver into the dk subsystem,
> if a disk is being resized?

Seems good to me. This could be triggered via a rescan via drvctl(8), or 
directly by driver if it can detect the property change.

Shrinking is always problematic, especially when you have to move blocks 
around (one example that comes to mind are PV removal of LVM), so it is 
more an exception than the rule. I would not expect disk(9) to cope with 
that -- this fits LVM more.

--
jym@