On Wed, 3 Aug 2022, Andrea Tomassetti wrote:
> Hi Coly,
> In one of our previous emails you said that
> > Currently bcache doesnʼt support cache or backing device resize
>
> I was investigating this point and I actually found a solution. I
> briefly tested it and it seems to work fine.
> Basically what I'm doing is:
> 1. Check if there's any discrepancy between the nr of sectors
> reported by the bcache backing device (holder) and the nr of sectors
> reported by its parent (slave).
> 2. If the number of sectors of the two devices are not the same,
> then call set_capacity_and_notify on the bcache device.
> 3. From user space, depending on the fs used, grow the fs with some
> utility (e.g. xfs_growfs)
>
> This works without any need of unmounting the mounted fs nor stopping
> the bcache backing device.
Well done! +1, would love to see a patch for this!
> So my question is: am I missing something? Can this live resize cause
> some problems (e.g. data loss)? Would it be useful if I send a patch on
> this?
A while a go we looked into doing this. Here is the summary of our
findings, not sure if there are any other considerations:
1. Create a sysfs file like /sys/block/bcache0/bcache/resize to trigger
resize on echo 1 >.
2. Refactor the set_capacity() bits from bcache_device_init() into its
own function.
3. Put locks around bcache_device.full_dirty_stripes and
bcache_device.stripe_sectors_dirty. Re-alloc+copy+free and zero the
new bytes at the end. Grep where bcache_device.full_dirty_stripes is
used and make sure it is locked appropriately, probably in the
writeback thread, maybe other places too.
The cachedev's don't know anything about the bdev size, so (according to
Kent) they will "just work" by referencing new offsets that were
previously beyond the disk. (This is basically the same as resizing the
bdev and then unregister/re-register which is how we resize bdevs now.)
As for resizing a cachedev, I've not looked at all---not sure about that
one. We always detach, resize, make-bcache and re-attach the new cache.
Maybe it is similarly simple, but haven't looked.
--
Eric Wheeler
>
> Kind regards,
> Andrea
>
