Documentation section of will give
you enough insight of multipath.
After installing multipath tools, you can find info about each
parameter of multipath.conf in


On Aug 28, 12:47 am, An Oneironaut <[EMAIL PROTECTED]> wrote:
> Ok,
>    To answer the questions.  The timeout time I have setup is 600
> seconds which is the limit of what I'd like to do.  The problem with a
> long time out is that every operation that could possibly happen on
> that mount will freeze up for ${TIMEOUT} seconds.  The worst one is
> reload which will freeze up, in the system I am working on it proves
> to be a major problem and I just can't push the timeout too far.
> Anyways what about the case where scsi device goes down at 2am and I
> don't see it till 10am the next day?
>   Instead what I have in place now is that the scsi connection will be
> torn down and the mount will be remounted as read only.  I then have a
> background script that keeps checking the iscsi device until it is
> back up again.  Once that happens it will restore the connection.
>   As far as multipath goes.  Is there any better documentation for
> this queue?  How big is the queue?  Is it a configurable size?  Why is
> the data only queue in multi-path and not the regular operation mode?
> Or rather why isn't there an option?
> I appreciate the comments.
> Thanks.
> On Aug 27, 6:29 am, Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
> > Konrad Rzeszutek schrieb:
> > > On Tue, Aug 26, 2008 at 11:37:46PM -0700, An Oneironaut wrote:
> > >> Hey all,
> > >>     I was wondering if anyone out there had tested open-iscsi with a
> > >> variety of Linux filesystems to see what works best.  Currently I am
> > >> using the ext3 fs and for months now have been suffering problems.
> > >> Anytime the iSCSI connection is dropped a variety of bad things can
> > >> happen.  The fs will get corrupted, I/O errors will occur when doing
> > >> shell operations on the volume, kernel oopses will occur, and so on.
> > >> Most of this is probably related to the state of the iSCSI device.
> > >> However tools like e2fsck take forever to fix a volume if it is 500
> > >> Gigs and up.
> > >>     Are there any suggestions out there for alternatives?  Or are
> > > Use multipath and make your iSCSI target use the 'queue_if_no_path' 
> > > configuration.
> > > Then you can use any filesystem on top of multipath and it won't matter
> > > that the underlaying connection is disconnected - the machine will
> > > just block the I/Os until it the iSCSI target is reconnected.
> > >> there better ext3 tools that can fix the fs quicker?  How are the rest
> > >> of you dealing with loss of connection and data corruption?
> > > multipath.
> > I think the easiest it to increase the
> > node.session.timeo.replacement_timeout in /etc/iscsi/iscsid.conf to
> > something more than default 120 seconds (which means that the connection
> > is dropped after 2 minutes; if you want to upgrade your target server
> > and change the cabling, you may need more time than two minutes).
> > --
> > Tomasz Chmielewski Hide quoted text -
> - Show quoted text -
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to