[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sanlock-devel
Subject:    Re: ask the detail about 'read' and 'write' in sanlock
From:       tsiren tsi <tsi0120 () gmail ! com>
Date:       2013-06-07 15:54:53
Message-ID: CAE+uQAm0v_0HE4o7dzv1PzsoY81Epij6qvHhg4Z6dt=G6smTTw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Thanks for your relpy.

I am reading the source code of sanlock, but the effect of  io delays must
be taken into consideration.

I will enlarge the parameter of sanlock_add_lockspace_timeout in case of io
delay.

Thank you very much. : )




2013/6/7 David Teigland <teigland@redhat.com>

> On Fri, Jun 07, 2013 at 10:27:43PM +0800, tsiren tsi wrote:
> > In the diskio.c, if the scsi command was used, the read or write timeout
> > error would be more circumstantial. When the read/write timeout occurs,
> the
> > scsi command could distinguish the actual reason, io busy, not ready,
> > hardware error and so on. If the reason was io busy, we  can enlarge the
> > timeout-time for robustness.
> >
> > What do you think about this?
>
> The only way I know of using scsi commands from userland is with sg.
> sg is not very practical for i/o, and would be a big code change.
> sanlock is used on multipath lvm LVs, which makes sg difficult.
> Also, sanlock can be used on both devices and NFS files, and it is
> nice to use the same code for both.
>
> A more reasonable suggestion would be to keep the existing i/o paths
> and use /dev/sg to get extra scsi information.  However, if you think
> about how sanlock works, this extra information would not really help.
> This is because it is not the host with i/o problems that needs extra
> information, it is the *other* hosts that are monitoring it.  All
> the other hosts would need to enlarge the timeout (and they would
> also need this new timeout to be consistent among everyone.)
>
> My suggestion is to monitor the io delays (and their causes) in your
> environment.  If you find there are io delays, caused by system/storage
> load, and they trigger timeouts (or come close to timing out), then
> enlarge the io timeout used with sanlock_add_lockspace_timeout.
>
> Dave
>

[Attachment #5 (text/html)]

<div dir="ltr"><div>Thanks for your relpy. <br><br>I am reading the source code of \
sanlock, but the effect of  io delays must be taken into consideration. \
<br><br></div><div>I will enlarge the parameter of sanlock_add_lockspace_timeout in \
case of io delay.<br> <br></div><div>Thank you very much. : \
)<br></div><div><br></div><br></div><div class="gmail_extra"><br><br><div \
class="gmail_quote">2013/6/7 David Teigland <span dir="ltr">&lt;<a \
href="mailto:teigland@redhat.com" \
target="_blank">teigland@redhat.com</a>&gt;</span><br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">On Fri, Jun 07, 2013 at 10:27:43PM +0800, \
tsiren tsi wrote:<br> &gt; In the diskio.c, if the scsi command was used, the read or \
write timeout<br> &gt; error would be more circumstantial. When the read/write \
timeout occurs, the<br> &gt; scsi command could distinguish the actual reason, io \
busy, not ready,<br> &gt; hardware error and so on. If the reason was io busy, we  \
can enlarge the<br> &gt; timeout-time for robustness.<br>
&gt;<br>
&gt; What do you think about this?<br>
<br>
</div>The only way I know of using scsi commands from userland is with sg.<br>
sg is not very practical for i/o, and would be a big code change.<br>
sanlock is used on multipath lvm LVs, which makes sg difficult.<br>
Also, sanlock can be used on both devices and NFS files, and it is<br>
nice to use the same code for both.<br>
<br>
A more reasonable suggestion would be to keep the existing i/o paths<br>
and use /dev/sg to get extra scsi information.  However, if you think<br>
about how sanlock works, this extra information would not really help.<br>
This is because it is not the host with i/o problems that needs extra<br>
information, it is the *other* hosts that are monitoring it.  All<br>
the other hosts would need to enlarge the timeout (and they would<br>
also need this new timeout to be consistent among everyone.)<br>
<br>
My suggestion is to monitor the io delays (and their causes) in your<br>
environment.  If you find there are io delays, caused by system/storage<br>
load, and they trigger timeouts (or come close to timing out), then<br>
enlarge the io timeout used with sanlock_add_lockspace_timeout.<br>
<br>
Dave<br>
</blockquote></div><br></div>


[Attachment #6 (text/plain)]

_______________________________________________
sanlock-devel mailing list
sanlock-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sanlock-devel


[prev in list] [next in list] [prev in thread] [next in thread]