Hot-grow bcache backing device.

[Eric Wheeler <bcache@xxxxxxxxxxxxxxxxxx>]

Hi Coli an Mingzhe:

Since Mingzhe brought up full_dirty_stripes in the other thread: some time 
ago I was looking into hot-resize of bcache devices.  Usually I resize by 
unregister/re-register but it would be nice to do hot.

While reviewing the code for feasibility the only snag I found was safely 
resizing full_dirty_stripes allocation before updating d->nr_stripes and 
calling set_capacity(d->disk, bdev_nr_sectors(dc->bdev)).

I think hot resize of a bdev should be simple and I have a few questions:

1. Should the newly resized bits of full_dirty_stripes just be zeroed?

2. Besides d->nr_stripes and full_dirty_stripes, does anything else need 
   to change size?  Long ago Kent confirmed that the cachedev structures 
   are bdev-size agnostic.

3. Are there any bcache locks to hold when resizing?

4. Is there something like "realloc()" to grow the allocation (I didn't 
   see kvzrealloc())---or would we need to kvzalloc into a new buffer, 
   copy in, and free the old one?

For reference, from bcache_device_init():
        n = DIV_ROUND_UP_ULL(sectors, d->stripe_size);
        [...]
        d->nr_stripes = n;

        n = d->nr_stripes * sizeof(atomic_t);
        d->stripe_sectors_dirty = kvzalloc(n, GFP_KERNEL);
        if (!d->stripe_sectors_dirty)
                return -ENOMEM;

        n = BITS_TO_LONGS(d->nr_stripes) * sizeof(unsigned long);
>>>>    d->full_dirty_stripes = kvzalloc(n, GFP_KERNEL); 



--
Eric Wheeler