don't use iSCSI or SAS with DM so I don't know if such a workaround is
wanted there too, but with FC it is necessary. Even if it is a bad
approach it is much better than nothing, the way I see it.
Regards
--
Tore Anderson
-
To unsubscribe from this list: send the line "unsubscri
The patch seems like a rather simple fix. Quick and dirty, sure, but it
would actually help out the likes of me who are putting this stuff in
production. And if it defaulted to remove_on_dev_loss=0, it wouldn't
really be intrusive either. It seems that it will take a while to get
thi
tic device removal would be a huge improvement for
me (and I doubt I'm the only one that feels this way).
Regards
--
Tore Anderson
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
s of reliability I experience now.
So what I suggest is a way of disabling dev_loss_tmo (or setting it to
unlimited). Think that's doable for a kernel newbie like me, or are
there any takers?
Regards
--
Tore Anderson
-
To unsubscribe from this list: send the line "unsubscribe linux-s
* Tore Anderson
> I can confirm that this patch solves my problem without any side
> effects (as far as I can tell).
I'm sorry I have to retract this statement. When I did some changes
on my storage array, it generated RSCNs and therefore I/O briefly
failed, causing timeou
oblems). I'm compiling a new kernel with Matthew Wilcox' patch now,
and will try a few more reboots to see how that helped. I'll post
about my findings tomorrow.
Regards
--
Tore Anderson
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the
6 matches
Mail list logo
