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