public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Pankaj Raghav <p.raghav@samsung.com>
To: dsterba@suse.cz,
	"Johannes Thumshirn" <Johannes.Thumshirn@wdc.com>,
	"Javier González" <javier@javigon.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Matias Bjørling" <Matias.Bjorling@wdc.com>,
	"Damien Le Moal" <damien.lemoal@opensource.wdc.com>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Keith Busch" <kbusch@kernel.org>,
	"Adam Manzanares" <a.manzanares@samsung.com>,
	"jiangbo.365@bytedance.com" <jiangbo.365@bytedance.com>,
	"kanchan Joshi" <joshi.k@samsung.com>,
	"Jens Axboe" <axboe@kernel.dk>,
	"Sagi Grimberg" <sagi@grimberg.me>,
	"Pankaj Raghav" <pankydev8@gmail.com>,
	"Kanchan Joshi" <joshiiitr@gmail.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-btrfs @ vger . kernel . org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 0/6] power_of_2 emulation support for NVMe ZNS devices
Date: Tue, 15 Mar 2022 20:56:34 +0100	[thread overview]
Message-ID: <bc4764d4-0532-6dac-fb4c-7325c0f3c626@samsung.com> (raw)
In-Reply-To: <20220315142740.GU12643@twin.jikos.cz>

Hi David,

On 2022-03-15 15:27, David Sterba wrote:
> 
> PO2 is really easy to work with and I guess allocation on the physical
> device could also benefit from that, I'm still puzzled why the NPO2 is
> even proposed.
> 
Quick recap:
Hardware NAND cannot naturally align to po2 zone sizes which led to
having a zone cap and zone size, where, zone cap is the actually storage
available in a zone. The main proposal is to remove the po2 constraint
to get rid of this LBA holes (generally speaking). That is why this
whole effort was started.

> We can possibly hide the calculations behind some API so I hope in the
> end it should be bearable. The size of block groups is flexible we only
> want some reasonable alignment.
>
I agree. I already replied to Johannes on what it might look like.
Reiterating here again, the reasonable alignment I was thinking while I
was doing a POC for btrfs with npo2 zone size is the minimum stripe size
that is required by btrfs (64K) to reduce the impact of this change on
the zoned support in btrfs.

> I haven't read the whole thread yet, my impression is that some hardware
> is deliberately breaking existing assumptions about zoned devices and in
> turn breaking btrfs support. I hope I'm wrong on that or at least that
> it's possible to work around it.
Based on the POC we did internally, it is definitely possible to support
it in btrfs. And making this change will not break the existing btrfs
support for zoned devices. Naive approach to making this change will
have some performance impact as we will be changing the po2 calculations
from log & shifts to division, multiplications. I definitely think we
can optimize it to minimize the impact on the existing deployments.

-- 
Regards,
Pankaj

  reply	other threads:[~2022-03-15 19:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220314073537.GA4204@lst.de>
     [not found] ` <05a1fde2-12bd-1059-6177-2291307dbd8d@opensource.wdc.com>
     [not found]   ` <20220314104938.hv26bf5vah4x32c2@ArmHalley.local>
     [not found]     ` <BYAPR04MB49682B9263F21EE67070A4B1F10F9@BYAPR04MB4968.namprd04.prod.outlook.com>
     [not found]       ` <20220314195551.sbwkksv33ylhlyx2@ArmHalley.local>
     [not found]         ` <BYAPR04MB49688BD817284E5C317DD5D8F1109@BYAPR04MB4968.namprd04.prod.outlook.com>
     [not found]           ` <20220315130501.q7fjpqzutadadfu3@ArmHalley.localdomain>
     [not found]             ` <BYAPR04MB49689803ED6E1E32C49C6413F1109@BYAPR04MB4968.namprd04.prod.outlook.com>
     [not found]               ` <20220315132611.g5ert4tzuxgi7qd5@unifi>
     [not found]                 ` <20220315133052.GA12593@lst.de>
     [not found]                   ` <20220315135245.eqf4tqngxxb7ymqa@unifi>
2022-03-15 14:14                     ` [PATCH 0/6] power_of_2 emulation support for NVMe ZNS devices Johannes Thumshirn
2022-03-15 14:27                       ` David Sterba
2022-03-15 19:56                         ` Pankaj Raghav [this message]
2022-03-15 15:11                       ` Javier González
2022-03-15 18:51                       ` Pankaj Raghav
2022-03-16  8:37                         ` Johannes Thumshirn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc4764d4-0532-6dac-fb4c-7325c0f3c626@samsung.com \
    --to=p.raghav@samsung.com \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=Matias.Bjorling@wdc.com \
    --cc=a.manzanares@samsung.com \
    --cc=axboe@kernel.dk \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=dsterba@suse.cz \
    --cc=hch@lst.de \
    --cc=javier@javigon.com \
    --cc=jiangbo.365@bytedance.com \
    --cc=joshi.k@samsung.com \
    --cc=joshiiitr@gmail.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=mcgrof@kernel.org \
    --cc=pankydev8@gmail.com \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox