Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758848AbcLBAyr (ORCPT ); Thu, 1 Dec 2016 19:54:47 -0500 Received: from szxga05-in.huawei.com ([119.145.14.199]:42179 "EHLO szxga05-in.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1757381AbcLBAyq (ORCPT ); Thu, 1 Dec 2016 19:54:46 -0500 Subject: Re: [PATCH 1/2] bcache: Remove redundant set_capacity To: Eric Wheeler References: <1480037969-45042-1-git-send-email-wangyijing@huawei.com> <583E32AE.5060106@huawei.com> <583FEC37.1040003@huawei.com> CC: , , , , , From: wangyijing Message-ID: <5840C641.30904@huawei.com> Date: Fri, 2 Dec 2016 08:54:25 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.177.23.4] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1946 Lines: 70 >>> 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 > 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 majordomo@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 majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> > > . >