Re: [RFC] Live resize of backing device

From: Eric Wheeler <bcache@lists.ewheeler.net>
To: Andrea Tomassetti <andrea.tomassetti-opensource@devo.com>
Cc: Coly Li <colyli@suse.de>,
	Kent Overstreet <kent.overstreet@gmail.com>,
	linux-bcache@vger.kernel.org
Subject: Re: [RFC] Live resize of backing device
Date: Fri, 5 Aug 2022 12:38:33 -0700 (PDT)	[thread overview]
Message-ID: <9474c19e-56f0-cb4d-68c-405c55aef281@ewheeler.net> (raw)
In-Reply-To: <CAHykVA5sgGooeRjM1EepCCpZqkvtQJ_=cY8hmjqe0oQ3FLDFnQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]

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
> 