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 -~----------~----~----~----~------~----~------~--~---