Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To:     Pankaj Raghav <p.raghav@samsung.com>,
        "dsterba@suse.cz" <dsterba@suse.cz>
CC:     "axboe@kernel.dk" <axboe@kernel.dk>,
        "damien.lemoal@opensource.wdc.com" <damien.lemoal@opensource.wdc.com>,
        "pankydev8@gmail.com" <pankydev8@gmail.com>,
        "dsterba@suse.com" <dsterba@suse.com>, "hch@lst.de" <hch@lst.de>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
        "jiangbo.365@bytedance.com" <jiangbo.365@bytedance.com>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "gost.dev@samsung.com" <gost.dev@samsung.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [PATCH v4 08/13] btrfs:zoned: make sb for npo2 zone devices align
 with sb log offsets
Thread-Topic: [PATCH v4 08/13] btrfs:zoned: make sb for npo2 zone devices
 align with sb log offsets
Thread-Index: AQHYaUWvGG/TZMkJWESbmBi0yiTiyA==
Date:   Thu, 19 May 2022 07:57:26 +0000
Message-ID: <PH0PR04MB7416FF84CE207FEC3ED8912F9BD09@PH0PR04MB7416.namprd04.prod.outlook.com>
References: <20220516165416.171196-1-p.raghav@samsung.com>
 <CGME20220516165429eucas1p272c8b4325a488675f08f2d7016aa6230@eucas1p2.samsung.com>
 <20220516165416.171196-9-p.raghav@samsung.com>
 <20220517124257.GD18596@twin.jikos.cz>
 <717a2c83-0678-9310-4c75-9ad5da0472f6@samsung.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?reqlWfoca+h8Q2F/lukhGj4Ck/Yz8Js3BU7SLX2ytFDdzU+/uzUsiNyGgQPF?=
 =?us-ascii?Q?yx/3GT3fr91n8Dx+EoiS6zB81tgXilI+pQcxekXoEmDjMbgEIVDoU1eV8jVw?=
 =?us-ascii?Q?woFPMMJ2C2/O4GTN2Em6UF/2O2MtlMczj0UyVPb9TYUvWIlxCVPbvNP2R7+s?=
 =?us-ascii?Q?RFrHombrwDOOmIkP6acCpmNajmFLvqBzSPVUnWCKvJuJ2Dr272XPP5f9iSZe?=
 =?us-ascii?Q?ekf0AvOkPBleFoEJ9PacujeX4oB3TBzhfrUdfseQXT3AHmhDnFYRbRwulQs1?=
 =?us-ascii?Q?pIJwn1H56gS7VixIIdAuMxYMRox6hoNhlLi4sWC8j2vowwDFkRVigvyAdJkN?=
 =?us-ascii?Q?Rm6bGJ+duzFhpXWXL45/b7mYPb9K3YLw3gDNl/CIINnuEUyKOVq6YE0XkIja?=
 =?us-ascii?Q?y6sNtiJwir1B8tP9Swm9bybIWPVKk+/4/53HpGo6qnwFLTO7JgSt1iek7J6a?=
 =?us-ascii?Q?kWKFRxCGeqEed18ehjd1efrE5bV7J9nP+uGbbVdPetVJZoIs3bSSiH+IbBJC?=
 =?us-ascii?Q?LCSGZrhnsFckvHEST/zBhMeaZ93slrEDZSU5gMSDUnyeL91lH0AaisNpGXRR?=
 =?us-ascii?Q?ffzaH2yRSz6BsnsQO+xxwBHi+vg5sbjKti4SQps8JhVBymuGUVGTydIjiqfI?=
 =?us-ascii?Q?RPAGP8bGy5w/o4JoigKiNxc6dX8+EXoUgrklQ9sQFMA2uawXImpvE6deq7Tw?=
 =?us-ascii?Q?R3EkrQ7YvPK+ZcZ5L/eMgeTjJG1b+ISKG2UQ6J12oUFko9qPX6JwZ+PuM4g7?=
 =?us-ascii?Q?JURDIqgWrE+2tD0cwRXBdSeCtwqUC1prpplHgvODjwmnlCjjhbR0aXAfVRv1?=
 =?us-ascii?Q?tUeB4/IlR7ucYRip5Cb2oa9x1969x9+tYZHNk6jaRlr0vqNf1s0OOaELbDx2?=
 =?us-ascii?Q?3g3klBiIzboW+vu4SAgZWcXEB+15L/D8kRs/Pkoerz4d4NcQ8wI3XY+ovXfZ?=
 =?us-ascii?Q?Sc5t9z5aJzJOKUKdzA6+l0R1FIvpXQYrMG5h7uJLk11Ic4152s/DZv7B14p4?=
 =?us-ascii?Q?CtOPFWkU3NvQlUIG3OVYrWvWi4X7zg1MvZaBkVxGzn+WBZ3WZrLOh54r1XDr?=
 =?us-ascii?Q?8a7yrzrX01GjZk6TRV9rOPXb6wgttm+vauWnCl6rScIiJZ05pxuArHyP37T2?=
 =?us-ascii?Q?HKzm9404suMITCHPgDucHg3lEDOejZN+rZjSdehPAMxvXi2mrxVYG357zooT?=
 =?us-ascii?Q?qlzpqYJSw+fSEUz+Umtxpr8kmF+G/zeLbErtlwo6xkxJzFAz3B6TnOH//pbQ?=
 =?us-ascii?Q?V4v1lRwywKedAuVs33gEAuvN6inmQWqSlP9wA+P4OQvhKPFNVPz1w1FWY/U8?=
 =?us-ascii?Q?PfIbOYwYoszzheLFbVPEs+RdZtAKVLbcOJY1N9OY0Hc4OKiBwCm0Ka/4mb/+?=
 =?us-ascii?Q?YmS9kRwCsRTIAWZaI2a9/9x/LrEEVToEuTaHpt+iKAdWJ/H1aRQSmpzzf2sB?=
 =?us-ascii?Q?RxjX3JxzGoA7PDztKQzjfY5wC/dMA0GT5WvNsW1IYdXAmCKi6O6egEi8d3B9?=
 =?us-ascii?Q?FAI5FXKPL375ulR/NyTvaMoUhr/cmJObpE3SwBhTDNvfhgPB54kts82++bQQ?=
 =?us-ascii?Q?tkgoXf5kS4ceyk1XfyTuvqxxAaNPaBXMJjWj5D6fYNdSgTbxyb5xN4moX8Da?=
 =?us-ascii?Q?MuNGytFNI5xtc4LodDHsNmLrg66RsVQZb9i+K57786C6+8sbsGXfhsPzGvX8?=
 =?us-ascii?Q?1LDlUmYHCcTGAlEGDVByEtgNE+pTIpl7cbJXaDy/An4t5IWqPHZEvilVHjVQ?=
 =?us-ascii?Q?7glNvQ07L9zaL+hoiZ5NclsPa+ef2GqZkqWu7fsZ/ZG9f6lU1geMCCJglJ0I?=
x-ms-exchange-antispam-messagedata-1: 3wsxfGTRpd/w+lvCmDa3nDbyOTPqNmmciagjxHpKh/Em1Yr+pJQW/DTm
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: wdc.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR04MB7416.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f0f9f08f-566c-44b4-e64f-08da396d36ff
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2022 07:57:26.2992
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: eWi1xnPp4MWOwR1HYrUoogbJUyQeffPr2QXBLcBSQyB2KDZKvq9YJCxalE84HKbdS49onoWEZujnoAyzM0QM3ZTsHlRJIRy/1txiHFChlGM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR04MB1180
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 18/05/2022 11:17, Pankaj Raghav wrote:=0A=
> On 2022-05-17 14:42, David Sterba wrote:=0A=
>> On Mon, May 16, 2022 at 06:54:11PM +0200, Pankaj Raghav wrote:=0A=
>>> Superblocks for zoned devices are fixed as 2 zones at 0, 512GB and 4TB.=
=0A=
>>> These are fixed at these locations so that recovery tools can reliably=
=0A=
>>> retrieve the superblocks even if one of the mirror gets corrupted.=0A=
>>>=0A=
>>> power of 2 zone sizes align at these offsets irrespective of their=0A=
>>> value but non power of 2 zone sizes will not align.=0A=
>>>=0A=
>>> To make sure the first zone at mirror 1 and mirror 2 align, write zero=
=0A=
>>> operation is performed to move the write pointer of the first zone to=
=0A=
>>> the expected offset. This operation is performed only after a zone rese=
t=0A=
>>> of the first zone, i.e., when the second zone that contains the sb is F=
ULL.=0A=
>> Is it a good idea to do the "write zeros", instead of a plain "set write=
=0A=
>> pointer"? I assume setting write pointer is instant, while writing=0A=
>> potentially hundreds of megabytes may take significiant time. As the=0A=
>> functions may be called from random contexts, the increased time may=0A=
>> become a problem.=0A=
>>=0A=
> Unfortunately it is not possible to just move the WP in zoned devices.=0A=
> The only alternative that I could use is to do write zeroes which are=0A=
> natively supported by some devices such as ZNS. It would be nice to know=
=0A=
> if someone had a better solution to this instead of doing write zeroes=0A=
> in zoned devices.=0A=
> =0A=
=0A=
I have another question. In case we need to pad the sb zone with a write=0A=
zeros and have a power fail between the write-zeros and the regular =0A=
super-block write, what happens? I know this padding is only done for the=
=0A=
backup super blocks, never the less it can happen and it can happen when=0A=
the primary super block is also corrupted.=0A=
=0A=
AFAIU we're then trying to reach out for a backup super block, look at the=
=0A=
write pointer and it only contains zeros but no super block, as only the =
=0A=
write-zeros has reached the device and not the super block write.=0A=
=0A=
How is this situation handled?=0A=
=0A=
Thanks,=0A=
	Johannes=0A=