lkml.org 
[lkml]   [2016]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] bcache: Remove redundant set_capacity
From
Date

>>> It probably is a duplicate set_capacity, but has anyone tested bringing on
>>> a writeback volume, and late-attaching the cache volume with this patch
>>> applied?
>>>
>>> Otherwise stated, is it possible to get the backing device attached
>>> without setting the capacity?
>>
>> Hi Eric, I tested this case in following steps, the result is fine, the capability is setted.
>>
>> [root@38 sys]# make-bcache -B /dev/nvme1n1
>> UUID: 6758bd42-c226-4de9-a6d5-fb003af63f9f
>> Set UUID: 2661eadd-79b4-4c56-a2fb-9f8b505aa9fd
>> version: 1
>> block_size: 1
>> data_offset: 16
>> [root@38 sys]# ls /dev/bcache
>> bcache/ bcache0
>> [root@38 sys]# fdisk -l
>> Disk /dev/nvme1n1: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> ....
>> Disk /dev/bcache0: 1.8 TiB, 2000398925824 bytes, 3907029152 sectors
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> ....
>> [root@38 sys]# make-bcache -C /dev/ram0
>> UUID: b64a4425-b9c1-4650-9cab-3856410c9566
>> Set UUID: a0a31965-a89d-43b6-a5d6-968897abeb7a
>> version: 0
>> nbuckets: 1024
>> block_size: 1
>> bucket_size: 1024
>> nr_in_set: 1
>> nr_this_dev: 0
>> first_bucket: 1
>> [root@38 sys]# echo a0a31965-a89d-43b6-a5d6-968897abeb7a > /sys/block/bcache0/bcache/attach
>> [root@38 sys]# echo writeback > /sys/block/bcache0/bcache/cache_mode
>> [root@38 sys]# mount /dev/bcache0 /tmp
>> [root@38 sys]# cd /tmp/
>> [root@38 tmp]# fio ~/fio_write.sh
>> file1: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
>> fio-2.2.8
>> Starting 1 thread
>> file1: Laying out IO file(s) (1 file(s) / 128MB)
>> Jobs: 1 (f=1): [w(1)] [0.0% done] [0KB/177.2MB/0KB /s] [0/45.4K/0 iops] [eta 05h:33m:13s]
>>
>> Thanks!
>> Yijing.
>
> 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" ?


> 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

\
 
 \ /
  Last update: 2016-12-01 10:25    [W:0.088 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site