Yes, the failfast is used to fix the problem you described. It can't remove
the active disk until all pending I/O finish without failfast. If there
is no
pending I/O, it can be removed immediately.
Thanks
Xiao
On 01/30/2019 10:14 PM, 李春 wrote:
I have read the description of the failfast f
https://bugzilla.kernel.org/show_bug.cgi?id=202425
--- Comment #3 from Bart Van Assche (bvanass...@acm.org) ---
On 1/30/19 7:42 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=202425
>
> --- Comment #2 from robert.smit...@protonmail.com ---
> (In reply
https://bugzilla.kernel.org/show_bug.cgi?id=202425
--- Comment #2 from robert.smit...@protonmail.com ---
(In reply to Bart Van Assche from comment #1)
> Can you bisect this issue to identify the commit that introduced this
> regression?
I found it. The commit is: 60db3a4d8cc9073cf56264785197ba75e
Bart,
> It would help if you could explain why you are so strongly opposed
> against keeping BIDI support in the kernel.
My preference is to remove it because there is simply no good use case
for it.
The fact that this peculiar command was once defined and has since been
obsoleted doesn't impl
On 2019/1/31 1:53, John Garry wrote:
On 30/01/2019 08:24, Jason Yan wrote:
The work flow of revalidation now is scanning expander phy by the
sequence of the phy and check if the phy have changed. This will leads
to an issue of swapping two sas disks on one expander.
Assume we have two sas di
Doug,
> The T10 members that I have spoken to, have expressed surprise that
> Linux kernel developers are contemplating removing SCSI bidi support.
> True, XDWRITEREAD and bidi friends have been removed from draft SBC-4
> but they are still used by RAID vendors and there is no move to deprecate
On 2019/1/31 1:36, John Garry wrote:
On 30/01/2019 08:24, Jason Yan wrote:
When we failed to discover the device, the phy address is still kept
in ex_phy. So when the next time we revalidate this phy the
address and device type is the same, it will be considered as flutter
and will not be dis
On 2019/1/31 1:22, John Garry wrote:
On 30/01/2019 08:24, Jason Yan wrote:
Now if a new device replaced a old device, the sas address will change.
Hmmm... not if it's a SATA disk, which would have some same invented SAS
address.
Yes, it's only for a SAS disk.
We unregister the old devi
On 2019/1/31 0:41, John Garry wrote:
On 30/01/2019 08:24, Jason Yan wrote:
sas_rediscover() returns error code if discover failed for a expander
phy. And sas_ex_revalidate_domain() only returns the last phy's error
code. So when sas_revalidate_domain() prints the return value of the
discover
On 2019/1/31 0:26, John Garry wrote:
On 30/01/2019 08:24, Jason Yan wrote:
When the event queue is full of phy up and down events and reached the
threshold, we will queue a shutdown-event, and set phy->in_shutdown so
that we will not queue a shutdown-event again. But before the
shutdown-event
On 2019/1/30 21:08, John Garry wrote:
On 30/01/2019 08:24, Jason Yan wrote:
If the device is unplugged or disconnected, the negotiated_linkrate
still can be seen from the userspace by sysfs. This makes people
confused and leaks information of the device last used. So let's reset
the negotiate
The aic94xx driver is currently failing to load with errors like
sysfs: cannot create duplicate filename
'/devices/pci:00/:00:03.0/:02:00.3/:07:02.0/revision'
Because the PCI code had recently added a file named 'revision' to
every PCI device. Fix this by renaming the aic94xx re
Since .scsi_done() must only be called after scsi_queue_rq() has
finished, make sure that the SRP initiator driver does not call
.scsi_done() while scsi_queue_rq() is in progress. Although
invoking sg_reset -d while I/O is in progress works fine with kernel
v4.20 and before, that is not the case wi
On Tue, Jan 22, 2019 at 10:25:20AM -0800, Bart Van Assche wrote:
> The default behavior of the SCSI core is to set the block layer request
> queue parameter max_segment_size to 64 KB. That means that elements of
> scatterlists are limited to 64 KB. Since RDMA adapters support larger
> sizes, increa
On Wed, 2019-01-30 at 17:50 -0500, Douglas Gilbert wrote:
> On 2019-01-30 3:23 p.m., Bart Van Assche wrote:
> > On Tue, 2019-01-22 at 15:47 -0500, Douglas Gilbert wrote:
> > > On 2019-01-22 1:25 p.m., Bart Van Assche wrote:
> > > > The default behavior of the SCSI core is to set the block layer req
On 2019-01-30 3:23 p.m., Bart Van Assche wrote:
On Tue, 2019-01-22 at 15:47 -0500, Douglas Gilbert wrote:
On 2019-01-22 1:25 p.m., Bart Van Assche wrote:
The default behavior of the SCSI core is to set the block layer request
queue parameter max_segment_size to 64 KB. That means that elements o
On Tue, 2019-01-22 at 15:47 -0500, Douglas Gilbert wrote:
> On 2019-01-22 1:25 p.m., Bart Van Assche wrote:
> > The default behavior of the SCSI core is to set the block layer request
> > queue parameter max_segment_size to 64 KB. That means that elements of
> > scatterlists are limited to 64 KB. S
On Wed, 2019-01-30 at 12:21 -0700, Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 10:59:34AM -0800, Bart Van Assche wrote:
> > On Tue, 2019-01-22 at 10:25 -0800, Bart Van Assche wrote:
> > > The default behavior of the SCSI core is to set the block layer request
> > > queue parameter max_segment_
On Wed, Jan 30, 2019 at 10:59:34AM -0800, Bart Van Assche wrote:
> On Tue, 2019-01-22 at 10:25 -0800, Bart Van Assche wrote:
> > The default behavior of the SCSI core is to set the block layer request
> > queue parameter max_segment_size to 64 KB. That means that elements of
> > scatterlists are li
Hello Bart,
First of all thanks for the feedback.
On 1/30/2019 5:54 PM, Bart Van Assche wrote:
> On Wed, 2019-01-30 at 18:48 +0100, Joao Pinto wrote:
>> Currently I am managing the Synopsys drivers & tools team (full-time) and
>> so I am passing the DWC UFS driver maintenance to Pedro Sousa.
>>
>
On Tue, 2019-01-22 at 10:25 -0800, Bart Van Assche wrote:
> The default behavior of the SCSI core is to set the block layer request
> queue parameter max_segment_size to 64 KB. That means that elements of
> scatterlists are limited to 64 KB. Since RDMA adapters support larger
> sizes, increase max_
On 30/01/2019 08:24, Jason Yan wrote:
The work flow of revalidation now is scanning expander phy by the
sequence of the phy and check if the phy have changed. This will leads
to an issue of swapping two sas disks on one expander.
Assume we have two sas disks, connected with expander phy10 and ph
On Wed, 2019-01-30 at 18:48 +0100, Joao Pinto wrote:
> Currently I am managing the Synopsys drivers & tools team (full-time) and
> so I am passing the DWC UFS driver maintenance to Pedro Sousa.
>
> Signed-off-by: Joao Pinto
> Cc: Pedro Sousa
> Cc: Marc Gonzalez
> Cc: Alex Lemberg
> ---
> MAIN
From: Giridhar Malavali
This patch adds new BIT detection to enable FC-NVMe feature in
the driver.
Signed-off-by: Giridhar Malavali
Signed-off-by: Himanshu Madhani
---
Hi Martin,
This patch adds additional bit to enable FC-NVMe in the driver.
Please apply this patch to 5.1/scsi-queue at you
Currently I am managing the Synopsys drivers & tools team (full-time) and
so I am passing the DWC UFS driver maintenance to Pedro Sousa.
Signed-off-by: Joao Pinto
Cc: Pedro Sousa
Cc: Marc Gonzalez
Cc: Alex Lemberg
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
On 30/01/2019 08:24, Jason Yan wrote:
When we failed to discover the device, the phy address is still kept
in ex_phy. So when the next time we revalidate this phy the
address and device type is the same, it will be considered as flutter
and will not be discovered again. So the device will not be
On 30/01/2019 08:24, Jason Yan wrote:
Now if a new device replaced a old device, the sas address will change.
Hmmm... not if it's a SATA disk, which would have some same invented SAS
address.
We unregister the old device and discover the new device in one
revalidation process. But after we
On 30/01/2019 08:24, Jason Yan wrote:
sas_rediscover() returns error code if discover failed for a expander
phy. And sas_ex_revalidate_domain() only returns the last phy's error
code. So when sas_revalidate_domain() prints the return value of the
discover process, we do not know if the revalidati
On Tue, 2019-01-29 at 09:35 +0100, Christoph Hellwig wrote:
> I disagree with investing further effort into BIDI support. It is
> dead for all practical purposes in standards and implementation,
> and the fact that we found all these bugs in it just further confirms
> that. The only answer to tha
On 30/01/2019 08:24, Jason Yan wrote:
When the event queue is full of phy up and down events and reached the
threshold, we will queue a shutdown-event, and set phy->in_shutdown so
that we will not queue a shutdown-event again. But before the
shutdown-event can be executed, every phy-down event wi
https://bugzilla.kernel.org/show_bug.cgi?id=201609
--- Comment #10 from Emil Velikov (emil.l.veli...@gmail.com) ---
(In reply to James.Bottomley from comment #9)
> On Wed, 2019-01-30 at 11:43 +, bugzilla-dae...@bugzilla.kernel.org
> wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=201609
https://bugzilla.kernel.org/show_bug.cgi?id=201609
--- Comment #9 from james.bottom...@hansenpartnership.com ---
On Wed, 2019-01-30 at 11:43 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=201609
>
> Emil Velikov (emil.l.veli...@gmail.com) changed:
On Wed, 2019-01-30 at 11:43 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=201609
>
> Emil Velikov (emil.l.veli...@gmail.com) changed:
>
>What|Removed |Added
>
https://bugzilla.kernel.org/show_bug.cgi?id=201609
--- Comment #8 from james.bottom...@hansenpartnership.com ---
On Wed, 2019-01-30 at 14:21 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=201609
>
> Bjorn Helgaas (bhelg...@google.com) changed:
>
>
On Wed, 2019-01-30 at 14:21 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=201609
>
> Bjorn Helgaas (bhelg...@google.com) changed:
>
>What|Removed |Added
>
Hi, Avri
>
>When we had a write descriptor query upiu, we appended the descriptor right
>after the bsg request. This was fine as the bsg driver allows to allocate
>whatever
>buffer we needed in its job request.
>
>Still, the proper way to deliver payload, however small (we only write config
>des
https://bugzilla.kernel.org/show_bug.cgi?id=201609
Bjorn Helgaas (bhelg...@google.com) changed:
What|Removed |Added
CC||bhelg...@google.com
I have read the description of the failfast feature. According to the
phenomenon, it may be not the problem of failfast.
Because when there are no io pressure, after stop the disk export on
the storage node, the disk will be automatically eliminate from the
md disk.
However, if there is continuou
Ok, thanks.
So we can look forward this bug will fix in rhel 6.11.
If my system is base on rhel 6.7, is there any way to solve it?
Xiao Ni 于2019年1月30日周三 下午5:15写道：
>
>
>
> On 01/30/2019 03:25 PM, Jack Wang wrote:
> > 李春 于2019年1月30日周三 上午7:08写道：
> >> # Description of problem:
> >> We loaded a disk
https://bugzilla.kernel.org/show_bug.cgi?id=201609
--- Comment #6 from Emil Velikov (emil.l.veli...@gmail.com) ---
I stand corrected:
The aic94xx revision file exposes a string (which look like hexadecimal number)
based on the revision number.
Regardless, the ideas proposed earlier are still appl
On 30/01/2019 08:24, Jason Yan wrote:
If the device is unplugged or disconnected, the negotiated_linkrate
still can be seen from the userspace by sysfs. This makes people
confused and leaks information of the device last used. So let's reset
the negotiated_linkrate after the phy is down.
Signed-
Presently when an error is encountered during probe of the cxlflash
adapter, a deadlock is seen with cpu thread stuck inside
cxlflash_remove(). Below is the trace of the deadlock as logged by
khungtaskd:
cxlflash 0006:00:00.0: cxlflash_probe: init_afu failed rc=-16
INFO: task kworker/80:1:890 bl
On 1/28/19 8:14 PM, James Smart wrote:
A scsi host lock is taken on every io completion to check whether
the abort handler is waiting on the io completion. This is an
expensive lock to take on all completion when rarely in an abort
condition.
Replace scsi host lock with command-specific lock. Sy
https://bugzilla.kernel.org/show_bug.cgi?id=201609
Emil Velikov (emil.l.veli...@gmail.com) changed:
What|Removed |Added
CC||emil.l.veli...@g
Hi, Stanley
I tested it on my own platform. This is very useful and thanks.
>
>Now uic errors are printed out of time order.
>
>Simply make it more readable by printing logs in time order, and printing "No
>record" if history is empty.
>
>Signed-off-by: Stanley Chu
>---
Reviewed-by: Bean Huo
Te
There is a potential NULL pointer dereference in case
fc_rport_create() fails and returns NULL.
Fixes: 2580064b5ec6 ("scsi: libfc: Replace ->rport_create callback with
function call")
Signed-off-by: YueHaibing
---
drivers/scsi/libfc/fc_lport.c | 4
1 file changed, 4 insertions(+)
diff --g
On 01/30/2019 03:25 PM, Jack Wang wrote:
李春 于2019年1月30日周三 上午7:08写道：
# Description of problem:
We loaded a disk from two network of storage node via iscsi, merged
into a disk through multipath, and made a raid1 with local disk by
mdadm.
However, when the storage machine of iscsi disk reboote
When we failed to discover the device, the phy address is still kept
in ex_phy. So when the next time we revalidate this phy the
address and device type is the same, it will be considered as flutter
and will not be discovered again. So the device will not be brought up.
Fix this by reset the phy a
sas_rediscover() returns error code if discover failed for a expander
phy. And sas_ex_revalidate_domain() only returns the last phy's error
code. So when sas_revalidate_domain() prints the return value of the
discover process, we do not know if the revalidation for every phy is
successful or not. W
When the event queue is full of phy up and down events and reached the
threshold, we will queue a shutdown-event, and set phy->in_shutdown so
that we will not queue a shutdown-event again. But before the
shutdown-event can be executed, every phy-down event will clear
phy->in_shutdown and a new shut
If the device is unplugged or disconnected, the negotiated_linkrate
still can be seen from the userspace by sysfs. This makes people
confused and leaks information of the device last used. So let's reset
the negotiated_linkrate after the phy is down.
Signed-off-by: Jason Yan
CC: John Garry
CC: J
The work flow of revalidation now is scanning expander phy by the
sequence of the phy and check if the phy have changed. This will leads
to an issue of swapping two sas disks on one expander.
Assume we have two sas disks, connected with expander phy10 and phy11:
phy10: 5000cca04eb1001d port-0:0:
Now if a new device replaced a old device, the sas address will change.
We unregister the old device and discover the new device in one
revalidation process. But after we deferred the sas_port_delete(), the
sas port is not deleted when we registering the new port and device.
The sas port cannot be
The work flow of revalidation now is scanning expander phy by the
sequence of the phy and check if the phy have changed. This will leads
to some issues of swapping disks or replacing a disk with a new one.
This patchset addresses the issues above by these main changes:
1. Let the revalidation firs
The ata device do not have a real sas address. If a ata device is
replaced with another one, the sas address is the same. Now libsas treat
this scenario as flutter and do not delete the old one and discover the
new one. This will cause the data read from or write to the wrong
device.
And also when
55 matches
Mail list logo
