>>> I want to make sure that the set_capacity call that happens on cache >>> attachment is not necessary when a backing device is attached without >> >> Hi Eric, set_capacity() which removed in this patch is happened at >> cached_dev_init() >> which is called when register a backing device, what do you mean >> "set_capacity call that happens on cache >>> attachment" ? > > > I'm sorry, you are correct. I though this was the cache-dev attachment, > not the cached-dev attachment. Looks good. > > Reviewed-by: Eric Wheeler <bca...@linux.ewheeler.net> >
Thanks！ > -- > Eric Wheeler > >> >> >>> its dirty writeback cache since bcache0 is not presented until the cache >>> attaches in that case. >> >> I found bcache0 device present once we do make-bcache -B /dev/nvme1n1. >> before attach the cache set. >> So I missed something ? >> >>> >>> Can you also unregister the volume, attach the backing device first, and >>> then the cache while the cache is dirty to make sure that the size is set >>> correctly? >> >> When I unregister the cache device, I found all the dirty data has been >> flushed to >> backing device, so how can I do the test the case as you point ? >> >> Thanks! >> Yijing. >> >>> >>> -- >>> Eric Wheeler >>> >>>> >>>>> >>>>> -Eric >>>>> >>>>>> dc->disk.disk->queue->backing_dev_info.ra_pages = >>>>>> max(dc->disk.disk->queue->backing_dev_info.ra_pages, >>>>>> q->backing_dev_info.ra_pages); >>>>>> -- >>>>>> 2.5.0 >>>>>> >>>>>> -- >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" >>>>>> in >>>>>> the body of a message to majord...@vger.kernel.org >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>>> >>>>> >>>>> . >>>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in >>>> the body of a message to majord...@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> > > . >
