linux-kernel - Re: [PATCH 1/2] bcache: Remove redundant set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LRH.2.11.1612011359150.22682@mail.ewheeler.net>
Date:   Thu, 1 Dec 2016 14:02:35 -0800 (PST)
From:   Eric Wheeler <bcache@...ts.ewheeler.net>
To:     wangyijing <wangyijing@...wei.com>
cc:     axboe@...com, kent.overstreet@...il.com, git@...ux.ewheeler.net,
        colyli@...e.de, linux-bcache@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] bcache: Remove redundant set_capacity

On Thu, 1 Dec 2016, wangyijing wrote:

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


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 <bcache@...ux.ewheeler.net>

--
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@...r.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@...r.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>