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 >