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