Re: [RFC] Live resize of backing device

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


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,

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
> >

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux