netdev
[Top] [All Lists]

Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics

To: Dmitry Yusupov <dmitry_yus@xxxxxxxxx>
Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics
From: Mike Christie <michaelc@xxxxxxxxxxx>
Date: Wed, 30 Mar 2005 12:10:58 -0800
Cc: open-iscsi@xxxxxxxxxxxxxxxx, Andi Kleen <ak@xxxxxx>, jamal <hadi@xxxxxxxxxx>, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>, Rik van Riel <riel@xxxxxxxxxx>, andrea@xxxxxxx, ksummit-2005-discuss@xxxxxxxxx, netdev <netdev@xxxxxxxxxxx>
In-reply-to: <1112204383.11620.2.camel@beastie>
References: <20050327054831.GA15453@xxxxxxxxx> <1111905181.4753.15.camel@mylaptop> <20050326224621.61f6d917.davem@xxxxxxxxxxxxx> <Pine.LNX.4.61.0503272245350.30885@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <m1zmwn21hk.fsf@xxxxxx> <1112027284.5531.27.camel@mulgrave> <20050329152008.GD63268@xxxxxx> <1112116762.5088.65.camel@beastie> <1112130512.1077.107.camel@xxxxxxxxxxxxxxxx> <20050330152208.GB12672@xxxxxx> <20050330172412.GP15453@xxxxxxxxx> <1112204383.11620.2.camel@beastie>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Dmitry Yusupov wrote:
On Wed, 2005-03-30 at 09:24 -0800, Matt Mackall wrote:
I seem to recall this being fairly easy to trigger by simply pulling
the network cable while there's heavy mmap + write load. The system
will quickly spiral down into OOM and will remain wedged when you plug
the network back in. With iSCSI, after some extended period all the
I/Os will have SCSI timeouts and lose everything.


We've discussed that already. SCSI timeout logic just doesn't fit. (see
rfc3720). For iSCSI, SCSI timeout logic *must* be disabled until iSCSI
recovery is complete.

This has actually been brought up when the scsi_times_out thread was going
on. It kinda was at least. Some driver writers inluding sfnet used to play
a lot of tricks with the timers to accomplish this (this was the goal
for sfnet at least) and I do not think linux-scsi will allow it. Maybe that
will change.

 host block/unblock logic in recent iSCSI transport
patch will help to implement that.


No it won't :( block/unblock does not disable timeouts it just makes it
so new commands are not queued and they timeout when the driver knows
that the transport is hosed.

<Prev in Thread] Current Thread [Next in Thread>