Konrad Rzeszutek wrote:
+/*
+ * Helper functions to parse data properly.
+ */
+static ssize_t sprintf_ipaddr(char *buf, u8 *ip)
+{
+ if (ip[0] == 0 ip[1] == 0 ip[2] == 0 ip[3] == 0
+ ip[4] == 0 ip[5] == 0 ip[6] == 0 ip[7] == 0
+ ip[8] == 0 ip[9] == 0 ip[10] ==
James Bottomley wrote:
However, there's still devloss_tmo to consider ... even in
multipath, I don't think you want to signal path failure until
devloss_tmo has fired otherwise you'll get too many transient up/down
events which damage performance if the array has an expensive failover
model.
James Bottomley wrote:
However, there's still devloss_tmo to consider ... even in
multipath, I don't think you want to signal path failure until
devloss_tmo has fired otherwise you'll get too many transient up/down
events which damage performance if the array has an expensive failover
model.
Joe Perches wrote:
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 57ce225..3cc21f5 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -1121,7 +1121,7 @@ iscsi_send(struct iscsi_conn *conn, struct
Joe Perches wrote:
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 57ce225..3cc21f5 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -1121,7 +1121,7 @@ iscsi_send(struct iscsi_conn *conn, struct
Michael S. Tsirkin wrote:
scsi/scsi_transport_iscsi.h uses struct mutex, so while
linux/mutex.h seems to be pulled in indirectly
by one of the headers it includes, the right thing
is to include linux/mutex.h directly.
Is that part about always including the header directly right? If so
then
Michael S. Tsirkin wrote:
scsi/scsi_transport_iscsi.h uses struct mutex, so while
linux/mutex.h seems to be pulled in indirectly
by one of the headers it includes, the right thing
is to include linux/mutex.h directly.
Is that part about always including the header directly right? If so
then
Jeremy Linton wrote:
Any function which use scsi_execute_async() and transfers "odd" sized
data that doesn't align correctly with the segment sizes may have its
transfer length padded out to the closest segment size.
For writes, this results in unnecessary data being transfered to the
SCSI
Jeremy Linton wrote:
Any function which use scsi_execute_async() and transfers odd sized
data that doesn't align correctly with the segment sizes may have its
transfer length padded out to the closest segment size.
For writes, this results in unnecessary data being transfered to the
SCSI
ED]>
>> Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
>>
>> Christoph passed me his patch to get rid of ->generic_packet() in the
>> cdrom layer, so the work is almost complete. This patch is fine as a
>> work-around until that gets merged, though.
>
> Actuall
. This patch is fine as a
work-around until that gets merged, though.
Actually, I think the new scsi request infrastructure should be doing
the bouncing (rather than have it done in each problem path we
discover).
Mike Christie tells me we're missing bouncing by accident in the
scsi_execute path
Mike Christie wrote:
> James Bottomley wrote:
>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
>>>> I can't even say if the tapes are written correctly as I can't read them
>>>> (one does not reboot production machines back to 2.4.x just to try to
>&
James Bottomley wrote:
> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
>>> I can't even say if the tapes are written correctly as I can't read them
>>> (one does not reboot production machines back to 2.4.x just to try to
>>> read a backup tape - I don'
Andreas Steinmetz wrote:
> As posted to lkml and linux-scsi on 2007-03-15 without reply, see
> http://marc.info/?l=linux-kernel=117395128412313=2 for original post:
>
> It is not so nice when one can write backup tapes but the tapes cannot
> be read. I don't know if memory management or the st
Andreas Steinmetz wrote:
As posted to lkml and linux-scsi on 2007-03-15 without reply, see
http://marc.info/?l=linux-kernelm=117395128412313w=2 for original post:
It is not so nice when one can write backup tapes but the tapes cannot
be read. I don't know if memory management or the st
James Bottomley wrote:
On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
I can't even say if the tapes are written correctly as I can't read them
(one does not reboot production machines back to 2.4.x just to try to
read a backup tape - I don't have 2.6.x older than 2.6.20
Mike Christie wrote:
James Bottomley wrote:
On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
I can't even say if the tapes are written correctly as I can't read them
(one does not reboot production machines back to 2.4.x just to try to
read a backup tape - I don't have 2.6.x older than
Kiyoshi Ueda wrote:
> Hi Jens,
>
> On Thu, 21 Dec 2006 08:49:47 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote:
>>> The new hook is needed for error handling in dm.
>>> For example, when an error occurred on a request, dm-multipath
>>> wants to try another path before returning EIO to application.
Jens Axboe wrote:
> On Thu, Dec 21 2006, Mike Christie wrote:
>> Jens Axboe wrote:
>>> On Thu, Dec 21 2006, Mike Christie wrote:
>>>> Mike Christie wrote:
>>>>> Jens Axboe wrote:
>>>>>> On Thu, Dec 21 2006, Mike Christie wr
Jens Axboe wrote:
> On Thu, Dec 21 2006, Mike Christie wrote:
>> Mike Christie wrote:
>>> Jens Axboe wrote:
>>>> On Thu, Dec 21 2006, Mike Christie wrote:
>>>>> Or the block layer code could set up the clone too. elv_next_request
>>>>> co
Mike Christie wrote:
> Jens Axboe wrote:
>> On Thu, Dec 21 2006, Mike Christie wrote:
>>> Or the block layer code could set up the clone too. elv_next_request
>>> could prep a clone based on the orignal request for the driver then dm
>>> would not have to worry
Jens Axboe wrote:
> On Thu, Dec 21 2006, Mike Christie wrote:
>> Or the block layer code could set up the clone too. elv_next_request
>> could prep a clone based on the orignal request for the driver then dm
>> would not have to worry about that part.
>
> It really c
Jens Axboe wrote:
> On Wed, Dec 20 2006, Kiyoshi Ueda wrote:
>> Hi Jens,
>>
>> On Wed, 20 Dec 2006 19:49:17 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote:
> Big NACK on this - it's not only really ugly, it's also buggy to pass
> interrupt flags as function arguments. As you also mention in
Mike Christie wrote:
> Jens Axboe wrote:
>> On Wed, Dec 20 2006, Kiyoshi Ueda wrote:
>>> Hi Jens,
>>>
>>> On Wed, 20 Dec 2006 19:49:17 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote:
>>>>>> Big NACK on this - it's not only really ugly
Mike Christie wrote:
Jens Axboe wrote:
On Wed, Dec 20 2006, Kiyoshi Ueda wrote:
Hi Jens,
On Wed, 20 Dec 2006 19:49:17 +0100, Jens Axboe [EMAIL PROTECTED] wrote:
Big NACK on this - it's not only really ugly, it's also buggy to pass
interrupt flags as function arguments. As you also mention
Jens Axboe wrote:
On Wed, Dec 20 2006, Kiyoshi Ueda wrote:
Hi Jens,
On Wed, 20 Dec 2006 19:49:17 +0100, Jens Axboe [EMAIL PROTECTED] wrote:
Big NACK on this - it's not only really ugly, it's also buggy to pass
interrupt flags as function arguments. As you also mention in the 0/1
mail, this
Jens Axboe wrote:
On Thu, Dec 21 2006, Mike Christie wrote:
Or the block layer code could set up the clone too. elv_next_request
could prep a clone based on the orignal request for the driver then dm
would not have to worry about that part.
It really can't, since it doesn't know how
Mike Christie wrote:
Jens Axboe wrote:
On Thu, Dec 21 2006, Mike Christie wrote:
Or the block layer code could set up the clone too. elv_next_request
could prep a clone based on the orignal request for the driver then dm
would not have to worry about that part.
It really can't, since
Jens Axboe wrote:
On Thu, Dec 21 2006, Mike Christie wrote:
Mike Christie wrote:
Jens Axboe wrote:
On Thu, Dec 21 2006, Mike Christie wrote:
Or the block layer code could set up the clone too. elv_next_request
could prep a clone based on the orignal request for the driver then dm
would
Jens Axboe wrote:
On Thu, Dec 21 2006, Mike Christie wrote:
Jens Axboe wrote:
On Thu, Dec 21 2006, Mike Christie wrote:
Mike Christie wrote:
Jens Axboe wrote:
On Thu, Dec 21 2006, Mike Christie wrote:
Or the block layer code could set up the clone too. elv_next_request
could prep a clone
Kiyoshi Ueda wrote:
Hi Jens,
On Thu, 21 Dec 2006 08:49:47 +0100, Jens Axboe [EMAIL PROTECTED] wrote:
The new hook is needed for error handling in dm.
For example, when an error occurred on a request, dm-multipath
wants to try another path before returning EIO to application.
Without the
Vladislav Bolkhovitin wrote:
Dave C Boutcher wrote:
On Wed, Sep 07, 2005 at 12:49:32PM +0200, Christoph Hellwig wrote:
On Tue, Sep 06, 2005 at 04:28:01PM -0500, Dave C Boutcher wrote:
This device driver provides the SCSI target side of the "virtual
SCSI" on IBM Power5 systems. The
FUJITA Tomonori wrote:
month. We discussed it with Christoph and decided that it would be
better to start from scratch because of the design differences.
Some of the things we are trying to improve upon are things that are
better supported in 2.6. Some differences:
- We will support
Dave C Boutcher wrote:
On Wed, Sep 07, 2005 at 12:49:32PM +0200, Christoph Hellwig wrote:
On Tue, Sep 06, 2005 at 04:28:01PM -0500, Dave C Boutcher wrote:
This device driver provides the SCSI target side of the "virtual
SCSI" on IBM Power5 systems. The initiator side has been in mainline
Dave C Boutcher wrote:
On Wed, Sep 07, 2005 at 12:49:32PM +0200, Christoph Hellwig wrote:
On Tue, Sep 06, 2005 at 04:28:01PM -0500, Dave C Boutcher wrote:
This device driver provides the SCSI target side of the virtual
SCSI on IBM Power5 systems. The initiator side has been in mainline
for
FUJITA Tomonori wrote:
month. We discussed it with Christoph and decided that it would be
better to start from scratch because of the design differences.
Some of the things we are trying to improve upon are things that are
better supported in 2.6. Some differences:
- We will support
Vladislav Bolkhovitin wrote:
Dave C Boutcher wrote:
On Wed, Sep 07, 2005 at 12:49:32PM +0200, Christoph Hellwig wrote:
On Tue, Sep 06, 2005 at 04:28:01PM -0500, Dave C Boutcher wrote:
This device driver provides the SCSI target side of the virtual
SCSI on IBM Power5 systems. The initiator
Mike Christie wrote:
> David Teigland wrote:
>
>>On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
>>
>>
>>>* Why are you using bufferheads extensively in a new filesystem?
>>
>>
>>bh's are used for metadata, the log, and jou
David Teigland wrote:
> On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
>
>>* Why are you using bufferheads extensively in a new filesystem?
>
>
> bh's are used for metadata, the log, and journaled data which need to be
> written at the block granularity, not page.
>
In a
David Teigland wrote:
On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
* Why are you using bufferheads extensively in a new filesystem?
bh's are used for metadata, the log, and journaled data which need to be
written at the block granularity, not page.
In a scsi tree
Mike Christie wrote:
David Teigland wrote:
On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
* Why are you using bufferheads extensively in a new filesystem?
bh's are used for metadata, the log, and journaled data which need to be
written at the block granularity, not page
Dmitry Yusupov wrote:
> On Sat, 2005-07-30 at 15:23 -0500, James Bottomley wrote:
>
>>On Sat, 2005-07-30 at 12:53 -0700, David S. Miller wrote:
>>
>>>From: James Bottomley <[EMAIL PROTECTED]>
>>>Date: Sat, 30 Jul 2005 12:32:42 -0500
>>>
>>>
FIB has taken your netlink number, so I changed it
Dmitry Yusupov wrote:
On Sat, 2005-07-30 at 15:23 -0500, James Bottomley wrote:
On Sat, 2005-07-30 at 12:53 -0700, David S. Miller wrote:
From: James Bottomley [EMAIL PROTECTED]
Date: Sat, 30 Jul 2005 12:32:42 -0500
FIB has taken your netlink number, so I changed it to 32
MAX_LINKS is 32,
Alex Aizman wrote:
This is to announce Open-iSCSI project: High-Performance iSCSI Initiator for
Linux.
MOTIVATION
==
Our initial motivations for the project were: (1) implement the right
user/kernel split, and (2) design iSCSI data path for performance. Recently
we added (3): get accepted
Alex Aizman wrote:
This is to announce Open-iSCSI project: High-Performance iSCSI Initiator for
Linux.
MOTIVATION
==
Our initial motivations for the project were: (1) implement the right
user/kernel split, and (2) design iSCSI data path for performance. Recently
we added (3): get accepted
Christoph Hellwig wrote:
+/* Code borrowed from dm-lsi-rdac by Mike Christie */
Any reason that module isn't submitted?
I do not have access to their HW specs, and have been busy with
some iscsi things so I did not have time to finish things up.
I was also hoping LSI would soon figure out
Christoph Hellwig wrote:
+/* Code borrowed from dm-lsi-rdac by Mike Christie */
Any reason that module isn't submitted?
I do not have access to their HW specs, and have been busy with
some iscsi things so I did not have time to finish things up.
I was also hoping LSI would soon figure out
201 - 247 of 247 matches
Mail list logo
