[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SN4PR0401MB3598C3B9A281C3748D24954C9B240@SN4PR0401MB3598.namprd04.prod.outlook.com>
Date: Fri, 11 Sep 2020 22:26:58 +0000
From: Johannes Thumshirn <Johannes.Thumshirn@....com>
To: Randy Dunlap <rdunlap@...radead.org>,
Borislav Petkov <bp@...en8.de>,
Damien Le Moal <Damien.LeMoal@....com>
CC: Christoph Hellwig <hch@....de>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Hannes Reinecke <hare@...e.de>, Jens Axboe <axboe@...nel.dk>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: first bad commit: [5795eb443060148796beeba106e4366d7f1458a6]
scsi: sd_zbc: emulate ZONE_APPEND commands
On 12/09/2020 00:22, Randy Dunlap wrote:
> On 9/11/20 3:17 PM, Borislav Petkov wrote:
>> On Fri, Sep 11, 2020 at 09:53:12PM +0200, Borislav Petkov wrote:
>>> Now, looking at that patch:
>>>
>>> 5795eb443060 ("scsi: sd_zbc: emulate ZONE_APPEND commands")
>>>
>>> yeah, that doesn't revert cleanly. But it talks about zoned-something
>>> devices and that rings a bell because you guys broke my zoned device
>>> once already:
>>
>> Ok, so Johannes and I poked a bit on IRC and here it is:
>>
>> # CONFIG_BLK_DEV_ZONED is not set.
>>
>> Enabling it, fixes the issue.
>>
>
> Uh, you are not saying that enabling that CONFIG_ is the final fix, are you?
>
> If so, do I need to enable it, even if I don't have a zoned block device?
>
No he does have a zoned block device and no this is not the final fix, I
think one of the stubbed out functions is broken, but it's midnight here
so we're calling it a day and chime back in on Monday.
And this setup is a bit special, as Boris is using partitions on a host-aware
zoned block device which is somewhat exotic (see add_partition()).
Byte,
Johannes
Powered by blists - more mailing lists