[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux1394-user
Subject:    Re: sbp2: sbp2util_node_write_no_wait failed
From:       Stefan Richter <stefanr () s5r6 ! in-berlin ! de>
Date:       2005-11-05 12:07:01
Message-ID: 436CA065.2000202 () s5r6 ! in-berlin ! de
[Download RAW message or body]

Michael Brade wrote:
> On Saturday 05 November 2005 01:36, Michael Brade wrote:
> 
>>>>It doesn't seem justified to lock up for 30 seconds
>>>>since a new label could be available much earlier. But that's just my
>>>>guess.
>>>
>>>These pauses aren't spent locked-up in sbp2. It is the period that the
>>>SCSI subsystem waits for completion of a task.
>>
>>I know... do you think I would put something at risk if I'd lower the
>>timeout to, say, 5 seconds? 30 seconds is *really* annoying.
> 
> Well, I just did it now, I put
> #define SD_TIMEOUT              (7 * HZ)
> in drivers/scsi/sd.c and I can tell you, finally it's fun again to work with 
> this hd :-) I'll see if it does any bad...

Perhaps you need to define this time-out specifically for normal I/O 
(that which bothers you most; I think that would be sd_probe, perhaps 
sd_prepare_flush too) and keep the standard time-out for the rest, like 
spin-up, read capacity, cache sync on device removal, and so on.

Note to other readers: Don't do this at home. A shorter SCSI timeout is 
only a hack, not a fix for sbp2's problems. It will just cause the 
command abortions to happen at higher frequency.
-- 
Stefan Richter
-=====-=-=-= =-== --=-=
http://arcgraph.de/sr/


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user
[prev in list] [next in list] [prev in thread] [next in thread]