In short:
Case A
Initiator: IBM x3550 (two NICs), /dev/sda (local disk), 100-120 MB/s
(hdparm -t /dev/sda).
Target:Dell (only one NIC), /dev/sda (local disk), dev/sda (IET
disk),70-90 MB/s(hdparm -t /dev/
(This is reportedly based on an actual experiment conducted in the U.K.)
*
*
*Put eight monkeys in a room. In the middle of the room is a ladder, leading
to a bunch of bananas hanging from a hook on the ceiling.*
*
*
*
*
*Each time a monkey tries to climb the ladder, all the monkeys are sprayed
wit
has anybody tested this with 10Gb cards? what is the performance gains?
I have tested it lightly and found that there are some gains but without
a 10Gb switch in the mix testing is very difficult.
Paul
Yao Wei wrote:
> In short:
>
> --
Hi,
perhaps this is the wrong mailing list, but anyway, perhaps anybody here can
help me:
iSCSI Enterprise Target is the projekt for the Linux implementation of a iSCSI
target. My question is wheather the software can be used to bind the same
target to two different initiators?
Thanks for an
On Tue, Sep 08, 2009 at 08:14:38PM +0200, Michael Schwartzkopff wrote:
>
> Hi,
>
> perhaps this is the wrong mailing list, but anyway, perhaps anybody here can
> help me:
>
> iSCSI Enterprise Target is the projekt for the Linux implementation of a
> iSCSI
> target. My question is wheather th
On 08/13/2009 02:58 AM, Hannes Reinecke wrote:
>
> Before we're trying to send a PDU we have to check whether a TMF
> is active. If so and if the PDU will be affected by the TMF
> we should allow only Data-out PDUs to be sent, or, if
> fast_abort is set, no PDUs at all.
>
Hey, I updated this patch
Is there a good way to monitor the iscsi sessions for errors? I need
to report it via SNMP (and perhaps kill the VM running over the
connection). Right now the only way I see is to monitor syslog -- but
the syslog doesn't always give me which session (or disk) is in
trouble.
Thanks
--
solidguy
--
On 09/10/2009 12:53 PM, solidguy wrote:
> Is there a good way to monitor the iscsi sessions for errors? I need
> to report it via SNMP (and perhaps kill the VM running over the
> connection). Right now the only way I see is to monitor syslog -- but
> the syslog doesn't always give me which session
This patch adds target reset support. If your driver was already setting
the sht->eh_target_reset_handler callout to iscsi_eh_target_reset you do
not have to make any code changes. The old
iscsi_eh_target_reset function was just dropping the session. Now it
will try a warm target reset. If that
Thanks. I'll take a look at the netlink interface. Not using multipath
for now, but will do so later.
For basic monitoring of storage network problems, here's what I am
thinking:
1. If there is a network failure, eventually cat /sys/block//
device/state should show "offline" ?
2. How long will th
Hi,
Very sorry for the previous mail which was actually intended for a few
people but somehow, by mistake got to all of the contacts and other mailing
lists I had ever sent a mail to.
I will take care that such a human error won't repeat again. Apologies
again!!
Thanks and Regards,
Nikhil
--~--~-
On 10 Sep 2009 at 10:53, solidguy wrote:
>
> Is there a good way to monitor the iscsi sessions for errors? I need
> to report it via SNMP (and perhaps kill the VM running over the
> connection). Right now the only way I see is to monitor syslog -- but
> the syslog doesn't always give me which se
12 matches
Mail list logo