Documentation section of http://christophe.varoqui.free.fr/ will give
you enough insight of multipath.
After installing multipath tools, you can find info about each
parameter of multipath.conf in
/usr/share/doc/device-mapper-multipath-0.4.7/multipath.conf.annotated
file.
Thanks
Nankdumar
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 Chmielewskihttp://wpkg.org- 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 open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
