tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: add disk size to "struct disk"?



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@


Home | Main Index | Thread Index | Old Index