Re: open-iscsi ideal filesystem?
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 -~--~~~~--~~--~--~---
Re: open-iscsi ideal filesystem?
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 -~--~~~~--~~--~--~---
Re: open-iscsi ideal filesystem?
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 http://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 -~--~~~~--~~--~--~---
Re: open-iscsi ideal filesystem?
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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
open-iscsi ideal filesystem?
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 there better ext3 tools that can fix the fs quicker? How are the rest of you dealing with loss of connection and data corruption? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---