Ok, thanks.
Xiao Ni 于2019年1月31日周四 下午2:25写道：
>
> 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 1
On 31/01/2019 01:11, Jason Yan wrote:
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 l
On 31/01/2019 02:13, Jason Yan wrote:
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
/s/phy/PHY/
in ex_phy. So when the next time we revalidate this phy the
address and device type is the same
>
>Signed-off-by: Avri Altman
>Reviewed-by: Evan Green
Reviewed-by: Bean Huo
On 31/01/2019 01:31, Jason Yan wrote:
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() pr
>-Original Message-
>From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>ow...@vger.kernel.org] On Behalf Of Avri Altman
>Sent: Sunday, January 27, 2019 8:08 AM
>To: James E.J. Bottomley ; Martin K. Petersen
>; linux-scsi@vger.kernel.org; linux-
>ker...@vger.kernel.org; Evan Green
On 31/01/2019 02:04, Jason Yan wrote:
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
On Thu, 31 Jan 2019 at 00:42, James Bottomley
wrote:
>
> 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 'r
On 31/01/2019 02:55, Jason Yan wrote:
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 on
On 31/01/2019 10:29, John Garry wrote:
On 31/01/2019 02:04, Jason Yan wrote:
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 invent
On 30/01/2019 12:43, Thomas Gleixner wrote:
On Wed, 30 Jan 2019, John Garry wrote:
On 29/01/2019 17:20, Keith Busch wrote:
On Tue, Jan 29, 2019 at 05:12:40PM +, John Garry wrote:
On 29/01/2019 15:44, Keith Busch wrote:
Hm, we used to freeze the queues with CPUHP_BLK_MQ_PREPARE callback,
On Wed, 2019-01-30 at 22:06 -0500, Martin K. Petersen wrote:
> > 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
On 2019/2/1 0:38, John Garry wrote:
On 31/01/2019 10:29, John Garry wrote:
On 31/01/2019 02:04, Jason Yan wrote:
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
On 2019/2/1 0:34, John Garry wrote:
On 31/01/2019 02:55, Jason Yan wrote:
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
Hi Bart,
> Removing bidi support will break bidi drivers. Does this mean that the
> osd driver should be removed before bidi support is removed from the
> SCSI core?
Yes. Christoph posted the patches a while back but I felt it was a bit
too late in the cycle to merge them for 5.0.
--
Martin K
Bart,
>> While the WARN_ON here looks helpful shouldn't we instead ensure that
>> sd_setup_rw6_cmnd never gets called with a 0 argument instead of bailing
>> out like this?
>
> Before I posted this patch I searched for code that submits read or
> write requests with length 0 but I haven't found
On Tue, Jan 29, 2019 at 03:03:18PM -0500, Douglas Gilbert wrote:
> So are you arguing that an oops that you had a hand in generating ***
> should not fixed, and should be used as a further reason to remove bidi
> completely from the kernel? Bebugging?
It is not the reason, but the final nail in th
On Wed, Jan 30, 2019 at 08:28:14AM -0800, Bart Van Assche wrote:
> It would help if you could explain why you are so strongly opposed against
> keeping BIDI support in the kernel.
It creates a barely tested code path all over the SCSI and block layers,
including a userspace attack vector. At the
The only real user of the T10 OSD protocol, the pNFS object layout
driver never went to the point of having shipping products, and we
removed it 1.5 years ago. Exofs is just a simple example without
real life users.
The code has been mostly unmaintained for years and is getting in the
way of bloc
We can just stash away the second request in struct bsg_job instead
of using the block layer req->next_rq field, allowing for the eventual
removal of the latter.
Signed-off-by: Christoph Hellwig
---
block/bsg-lib.c | 44 +---
block/bsg.c |
Unused now, and another field in struct request bites the dust.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-debugfs.c | 1 -
block/blk-mq.c | 3 ---
include/linux/blkdev.h | 6 --
3 files changed, 10 deletions(-)
diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
ind
Move all actual functionality into helpers, just leaving the dispatch
in this function.
Signed-off-by: Christoph Hellwig
Reviewed-by: Benjamin Block
Tested-by: Benjamin Block
Tested-by: Avri Altman
---
block/bsg.c | 158
1 file changed, 72
No real need for bidi support once the OSD code is gone.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/cxgbi/libcxgbi.c | 13 +++---
drivers/scsi/iscsi_tcp.c | 9 +
drivers/scsi/libiscsi.c| 64 +++---
drivers/scsi/libiscsi_tcp.c
No users left.
Signed-off-by: Christoph Hellwig
---
block/blk-mq.c | 1 -
include/linux/blkdev.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 3ba37b9e15e9..502cbf964a3b 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -331,7 +331,6 @@ sta
Now that all the users are gone the SCSI OSD library can be removed
as well.
Signed-off-by: Christoph Hellwig
---
Documentation/scsi/osd.txt | 192 ---
MAINTAINERS |6 -
drivers/scsi/Kconfig |2 -
drivers/scsi/Makefile|1 -
drivers/
No more need in a blk-mq world where the scsi command and request
are allocated together.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/qedf/qedf_io.c | 6 --
drivers/scsi/qedi/qedi_fw.c | 7 ---
drivers/scsi/scsi_lib.c | 3 ---
drivers/scsi/sr.c | 1 -
4 files changed,
26 matches
Mail list logo
