Hi Coly,
I have finally some time to work on the patch. I already have a first
prototype that seems to work but, before sending it, I would like to
ask you two questions:
1. Inspecting the code, I found that the only lock mechanism is the
writeback_lock semaphore. Am I correct?
2. How can I effectively test my patch? So far I'm doing something like this:
a. make-bcache --writeback -B /dev/vdb -C /dev/vdc
b. mkfs.xfs /dev/bcache0
c. dd if=/dev/random of=/mnt/random bs=1M count=1000
d. md5sum /mnt/random | tee /mnt/random.md5
e. live resize the disk and repeat c. and d.
f. umount/reboot/remount and check that the md5 hashes are correct
Any suggestions?
Thank you very much,
Andrea
On Fri, Aug 5, 2022 at 9:38 PM Eric Wheeler <bcache@xxxxxxxxxxxxxxxxxx> wrote:
>
> 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
> >
