From mboxrd@z Thu Jan 1 00:00:00 1970 From: Coly Li Subject: Re: [RFC PATCH v2] bcache: export zoned information for backing device Date: Mon, 11 May 2020 01:24:11 +0800 Message-ID: References: <20200510165232.67500-1-colyli@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20200510165232.67500-1-colyli@suse.de> Content-Language: en-US Sender: linux-block-owner@vger.kernel.org To: Damien Le Moal , Johannes Thumshirn Cc: linux-bcache@vger.kernel.org, linux-block@vger.kernel.org, Hannes Reinecke List-Id: linux-bcache@vger.kernel.org On 2020/5/11 00:52, Coly Li wrote: > This is a very basic zoned device support. With this patch, bcache > device is able to, > - Export zoned device attribution via sysfs > - Response report zones request, e.g. by command 'blkzone report' > But the bcache device is still NOT able to, > - Response any zoned device management request or IOCTL command > > Here are the testings I have done, > - read /sys/block/bcache0/queue/zoned, content is 'host-managed' > - read /sys/block/bcache0/queue/nr_zones, content is number of zones > including all zone types. > - read /sys/block/bcache0/queue/chunk_sectors, content is zone size > in sectors. > - run 'blkzone report /dev/bcache0', all zones information displayed. > - run 'blkzone reset /dev/bcache0', operation is rejected with error > information: "blkzone: /dev/bcache0: BLKRESETZONE ioctl failed: > Operation not supported" > - Sequential writes by dd, I can see some zones' write pointer 'wptr' > values updated. > > All of these are very basic testings, if you have better testing > tools or cases, please offer me hint. > > Thanks in advance for your review and comments. > > Signed-off-by: Coly Li > CC: Hannes Reinecke > CC: Damien Le Moal > CC: Johannes Thumshirn > --- Hi Damien and Johannes, With this patch the bcache device with a SMR drive can export the zone information and format zonefs on top of it. Writeback mode does not work at this moment (it requires on-disk format change and on my to-do list), writethrough and writearound mode can be used on the bcache device to accelerate random read when hitting. During my testing, there are 2 things needs to fix. 1, mkzonefs report the first zone size does not match. Because bcache occupies the first 8KB of the backing SMR drive, so the first zone size is 8KB less. By ignoring unmatched zone 0 size, mkzonefs works and the bcache device is formated. 2, Direct I/O on files under seq/ directory can not be accessed. I need help here. It seems direct I/O write fails with -EINVAL. I found the failure happens in fs/iomap/direct-io.c:iomap_dio_bio_actor(), 211 if ((pos | length | align) & ((1 << blkbits) - 1)) 212 return -EINVAL; When I write to seq/1 file on offset 0 with 4096 bytes, in the above line, align is 205427296, and (pos | length | align) & ((1 << blkbits) - 1) is non-zero. Then all writes to files under seq/ fail with -EINVAL. I guess there should be something missing when I do the direct I/O write. Could you all give me some hint ? Thanks in advance. Coly Li From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C28EC38A2A for ; Sun, 10 May 2020 17:24:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F17D8207DD for ; Sun, 10 May 2020 17:24:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729076AbgEJRYT (ORCPT ); Sun, 10 May 2020 13:24:19 -0400 Received: from mx2.suse.de ([195.135.220.15]:58858 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728360AbgEJRYT (ORCPT ); Sun, 10 May 2020 13:24:19 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AC0D0ACAD; Sun, 10 May 2020 17:24:19 +0000 (UTC) Cc: linux-bcache@vger.kernel.org, linux-block@vger.kernel.org, Hannes Reinecke References: <20200510165232.67500-1-colyli@suse.de> To: Damien Le Moal , Johannes Thumshirn From: Coly Li Autocrypt: addr=colyli@suse.de; keydata= mQINBFYX6S8BEAC9VSamb2aiMTQREFXK4K/W7nGnAinca7MRuFUD4JqWMJ9FakNRd/E0v30F qvZ2YWpidPjaIxHwu3u9tmLKqS+2vnP0k7PRHXBYbtZEMpy3kCzseNfdrNqwJ54A430BHf2S GMVRVENiScsnh4SnaYjFVvB8SrlhTsgVEXEBBma5Ktgq9YSoy5miatWmZvHLFTQgFMabCz/P j5/xzykrF6yHo0rHZtwzQzF8rriOplAFCECp/t05+OeHHxjSqSI0P/G79Ll+AJYLRRm9til/ K6yz/1hX5xMToIkYrshDJDrUc8DjEpISQQPhG19PzaUf3vFpmnSVYprcWfJWsa2wZyyjRFkf J51S82WfclafNC6N7eRXedpRpG6udUAYOA1YdtlyQRZa84EJvMzW96iSL1Gf+ZGtRuM3k49H 1wiWOjlANiJYSIWyzJjxAd/7Xtiy/s3PRKL9u9y25ftMLFa1IljiDG+mdY7LyAGfvdtIkanr iBpX4gWXd7lNQFLDJMfShfu+CTMCdRzCAQ9hIHPmBeZDJxKq721CyBiGAhRxDN+TYiaG/UWT 7IB7LL4zJrIe/xQ8HhRO+2NvT89o0LxEFKBGg39yjTMIrjbl2ZxY488+56UV4FclubrG+t16 r2KrandM7P5RjR+cuHhkKseim50Qsw0B+Eu33Hjry7YCihmGswARAQABtBhDb2x5IExpIDxj b2x5bGlAc3VzZS5kZT6JAlYEEwEIAEACGyMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgBYh BOo+RS/0+Uhgjej60Mc5B5Nrffj8BQJcR84dBQkY++fuAAoJEMc5B5Nrffj8ixcP/3KAKg1X EcoW4u/0z+Ton5rCyb/NpAww8MuRjNW82UBUac7yCi1y3OW7NtLjuBLw5SaVG5AArb7IF3U0 qTOobqfl5XHsT0o5wFHZaKUrnHb6y7V3SplsJWfkP3JmOooJsQB3z3K96ZTkFelsNb0ZaBRu gV+LA4MomhQ+D3BCDR1it1OX/tpvm2uaDF6s/8uFtcDEM9eQeqATN/QAJ49nvU/I8zDSY9rc 0x9mP0x+gH4RccbnoPu/rUG6Fm1ZpLrbb6NpaYBBJ/V1BC4lIOjnd24bsoQrQmnJn9dSr60X 1MY60XDszIyzRw7vbJcUn6ZzPNFDxFFT9diIb+wBp+DD8ZlD/hnVpl4f921ZbvfOSsXAJrKB 1hGY17FPwelp1sPcK2mDT+pfHEMV+OQdZzD2OCKtza/5IYismJJm3oVUYMogb5vDNAw9X2aP XgwUuG+FDEFPamFMUwIfzYHcePfqf0mMsaeSgtA/xTxzx/0MLjUJHl46Bc0uKDhv7QUyGz0j Ywgr2mHTvG+NWQ/mDeHNGkcnsnp3IY7koDHnN2xMFXzY4bn9m8ctqKo2roqjCzoxD/njoAhf KBzdybLHATqJG/yiZSbCxDA1n/J4FzPyZ0rNHUAJ/QndmmVspE9syFpFCKigvvyrzm016+k+ FJ59Q6RG4MSy/+J565Xj+DNY3/dCuQINBFYX6S8BEADZP+2cl4DRFaSaBms08W8/smc5T2CO YhAoygZn71rB7Djml2ZdvrLRjR8Qbn0Q/2L2gGUVc63pJnbrjlXSx2LfAFE0SlfYIJ11aFdF 9w7RvqWByQjDJor3Z0fWvPExplNgMvxpD0U0QrVT5dIGTx9hadejCl/ug09Lr6MPQn+a4+qs aRWwgCSHaIuDkH3zI1MJXiqXXFKUzJ/Fyx6R72rqiMPHH2nfwmMu6wOXAXb7+sXjZz5Po9GJ g2OcEc+rpUtKUJGyeQsnCDxUcqJXZDBi/GnhPCcraQuqiQ7EGWuJfjk51vaI/rW4bZkA9yEP B9rBYngbz7cQymUsfxuTT8OSlhxjP3l4ZIZFKIhDaQeZMj8pumBfEVUyiF6KVSfgfNQ/5PpM R4/pmGbRqrAAElhrRPbKQnCkGWDr8zG+AjN1KF6rHaFgAIO7TtZ+F28jq4reLkur0N5tQFww wFwxzROdeLHuZjL7eEtcnNnzSkXHczLkV4kQ3+vr/7Gm65mQfnVpg6JpwpVrbDYQeOFlxZ8+ GERY5Dag4KgKa/4cSZX2x/5+KkQx9wHwackw5gDCvAdZ+Q81nm6tRxEYBBiVDQZYqO73stgT ZyrkxykUbQIy8PI+g7XMDCMnPiDncQqgf96KR3cvw4wN8QrgA6xRo8xOc2C3X7jTMQUytCz9 0MyV1QARAQABiQI8BBgBCAAmAhsMFiEE6j5FL/T5SGCN6PrQxzkHk2t9+PwFAlxHziAFCRj7 5/EACgkQxzkHk2t9+PxgfA//cH5R1DvpJPwraTAl24SUcG9EWe+NXyqveApe05nk15zEuxxd e4zFEjo+xYZilSveLqYHrm/amvQhsQ6JLU+8N60DZHVcXbw1Eb8CEjM5oXdbcJpXh1/1BEwl 4phsQMkxOTns51bGDhTQkv4lsZKvNByB9NiiMkT43EOx14rjkhHw3rnqoI7ogu8OO7XWfKcL CbchjJ8t3c2XK1MUe056yPpNAT2XPNF2EEBPG2Y2F4vLgEbPv1EtpGUS1+JvmK3APxjXUl5z 6xrxCQDWM5AAtGfM/IswVjbZYSJYyH4BQKrShzMb0rWUjkpXvvjsjt8rEXpZEYJgX9jvCoxt oqjCKiVLpwje9WkEe9O9VxljmPvxAhVqJjX62S+TGp93iD+mvpCoHo3+CcvyRcilz+Ko8lfO hS9tYT0HDUiDLvpUyH1AR2xW9RGDevGfwGTpF0K6cLouqyZNdhlmNciX48tFUGjakRFsxRmX K0Jx4CEZubakJe+894sX6pvNFiI7qUUdB882i5GR3v9ijVPhaMr8oGuJ3kvwBIA8lvRBGVGn 9xvzkQ8Prpbqh30I4NMp8MjFdkwCN6znBKPHdjNTwE5PRZH0S9J0o67IEIvHfH0eAWAsgpTz +jwc7VKH7vkvgscUhq/v1/PEWCAqh9UHy7R/jiUxwzw/288OpgO+i+2l11Y= Subject: Re: [RFC PATCH v2] bcache: export zoned information for backing device Message-ID: Date: Mon, 11 May 2020 01:24:11 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200510165232.67500-1-colyli@suse.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-bcache-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bcache@vger.kernel.org Message-ID: <20200510172411.51nRnYSOBi5Th9cbIs9wwPwN0Rh3b9lguBWE_RgpCY4@z> On 2020/5/11 00:52, Coly Li wrote: > This is a very basic zoned device support. With this patch, bcache > device is able to, > - Export zoned device attribution via sysfs > - Response report zones request, e.g. by command 'blkzone report' > But the bcache device is still NOT able to, > - Response any zoned device management request or IOCTL command > > Here are the testings I have done, > - read /sys/block/bcache0/queue/zoned, content is 'host-managed' > - read /sys/block/bcache0/queue/nr_zones, content is number of zones > including all zone types. > - read /sys/block/bcache0/queue/chunk_sectors, content is zone size > in sectors. > - run 'blkzone report /dev/bcache0', all zones information displayed. > - run 'blkzone reset /dev/bcache0', operation is rejected with error > information: "blkzone: /dev/bcache0: BLKRESETZONE ioctl failed: > Operation not supported" > - Sequential writes by dd, I can see some zones' write pointer 'wptr' > values updated. > > All of these are very basic testings, if you have better testing > tools or cases, please offer me hint. > > Thanks in advance for your review and comments. > > Signed-off-by: Coly Li > CC: Hannes Reinecke > CC: Damien Le Moal > CC: Johannes Thumshirn > --- Hi Damien and Johannes, With this patch the bcache device with a SMR drive can export the zone information and format zonefs on top of it. Writeback mode does not work at this moment (it requires on-disk format change and on my to-do list), writethrough and writearound mode can be used on the bcache device to accelerate random read when hitting. During my testing, there are 2 things needs to fix. 1, mkzonefs report the first zone size does not match. Because bcache occupies the first 8KB of the backing SMR drive, so the first zone size is 8KB less. By ignoring unmatched zone 0 size, mkzonefs works and the bcache device is formated. 2, Direct I/O on files under seq/ directory can not be accessed. I need help here. It seems direct I/O write fails with -EINVAL. I found the failure happens in fs/iomap/direct-io.c:iomap_dio_bio_actor(), 211 if ((pos | length | align) & ((1 << blkbits) - 1)) 212 return -EINVAL; When I write to seq/1 file on offset 0 with 4096 bytes, in the above line, align is 205427296, and (pos | length | align) & ((1 << blkbits) - 1) is non-zero. Then all writes to files under seq/ fail with -EINVAL. I guess there should be something missing when I do the direct I/O write. Could you all give me some hint ? Thanks in advance. Coly Li