[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b1a9c348-d3c6-1786-9c51-763cec1f2384@huawei.com>
Date: Fri, 1 Nov 2024 10:17:10 +0800
From: yangxingui <yangxingui@...wei.com>
To: Niklas Cassel <cassel@...nel.org>, Damien Le Moal <dlemoal@...nel.org>
CC: Yu Kuai <yukuai1@...weicloud.com>, <axboe@...nel.dk>, John Garry
<john.g.garry@...cle.com>, <linux-block@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <James.Bottomley@...senpartnership.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>, "yukuai (C)"
<yukuai3@...wei.com>, "yangerkun@...wei.com" <yangerkun@...wei.com>
Subject: Re: [bug report] block: Non-NCQ commands will never be executed while
fio is continuously running
On 2024/10/31 22:12, Niklas Cassel wrote:
> On Thu, Sep 19, 2024 at 04:14:15PM +0200, Damien Le Moal wrote:
>> On 2024/09/19 14:26, Yu Kuai wrote:
>>>
>>> Does libata return a specific value in this case? If so, maybe we can
>>> stop other hctx untill this IO is handled.
>>>
>>> For now, I think libata should use single hctx, it just doesn't support
>>> multiple hctx yet.
>>
>> libata does not care/know about hctx. It only issues commands to ATA devices,
>> which always are single queue. And pure SATA adapters like AHCI are always
>> single queue.
>>
>> The issue at hand can happen only for libsas based SAS HBAs that have multiple
>> command submission queues (with a shared tag set). Commands for the same device
>> may end up being submitted through different queues, and when the submitted
>> commands include a mix of NCQ and non-NCQ commands, the problem happens without
>> libata being able to easily do anything about it, and not possible control
>> possible at the scsi layer either since the commands submitted are SCSI (not yet
>> translated to ATA commands) which do not have any NCQ/non-NCQ exclusion
>> knowledge at all. NCQ is an ATA concept unknown to the scsi and block layer.
>>
>> We (Niklas and I) are trying to find a solution, but that may not be within
>> libata itself. It may need changes to libsas as well. Not sure yet. Still exploring.
>
> Hello Xingui,
>
> I send a proposed solution to this problem here:
> https://lore.kernel.org/linux-ide/20241031140731.224589-4-cassel@kernel.org/
>
> Please test and see if it addresses your problem.
>
OK, thanks for following this issue and fixing it, we will verify it as
soon as possible.
Thanks.
Xingui
Powered by blists - more mailing lists