<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 15, 2014 at 12:01 PM, Prashanth Pai <span dir="ltr">&lt;<a href="mailto:ppai@redhat.com" target="_blank">ppai@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;m not sure if this is related but worth taking note of: write-behind when sees a shorter write, it chooses to ignore ENOSPC or EDQUOT that it received from the brick and will return a generic EIO sometimes.<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=986812" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=986812</a><br></blockquote><div><br></div><div>Thats a different problem not relevant in this context.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
 -Prashanth Pai<br>
<div class="HOEnZb"><div class="h5"><br>
----- Original Message -----<br>
From: &quot;Raghavendra G&quot; &lt;<a href="mailto:raghavendra@gluster.com">raghavendra@gluster.com</a>&gt;<br>
To: &quot;Emmanuel Dreyfus&quot; &lt;<a href="mailto:manu@netbsd.org">manu@netbsd.org</a>&gt;<br>
Cc: &quot;Gluster Devel&quot; &lt;<a href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a>&gt;<br>
Sent: Wednesday, October 15, 2014 11:50:36 AM<br>
Subject: Re: [Gluster-devel] quota<br>
<br>
On Tue, Oct 14, 2014 at 9:18 AM, Emmanuel Dreyfus &lt; <a href="mailto:manu@netbsd.org">manu@netbsd.org</a> &gt; wrote:<br>
<br>
<br>
Vijay Bellur &lt; <a href="mailto:vbellur@redhat.com">vbellur@redhat.com</a> &gt; wrote:<br>
<br>
&gt; You would need to set features.soft-timeout and features.hard-timeout<br>
&gt; values to 0 when testing with lower values of directory quota.<br>
<br>
It works more like expected this way, but there are still oddities: for<br>
instance once quota is reached, I can still append smal chunk to a file,<br>
and do it a lot of times.<br>
<br>
A few debug printf tell me this is because of write-behind: the writing<br>
process gets success, then glusterfs attemps to write - and fail. This<br>
means we silently discard data, which does not looks nice. Is it the<br>
expected behavior or is it a NetBSD bug?<br>
<br>
It happens on other environments too. Applications receive success for writes and writes wouldn&#39;t have happened on the brick. Write-behind propagates failures of cached-writes to application in the first file operation after write-failure to brick. In the worst case the application would see a non-zero return value for close of the fd. However not all applications check return value of close and hence write failures would go unnoticed by application.<br>
<br>
This behaviour is posix-conformant. From man 2 close,<br>
<br>
&lt;man 2 close&gt;<br>
<br>
NOTES<br>
Not checking the return value of close() is a common but nevertheless serious programming error. It is quite possible that errors on a<br>
previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to<br>
silent loss of data. This can especially be observed with NFS and with disk quota.<br>
<br>
A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for<br>
a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It<br>
will depend on the disk hardware at this point.)<br>
<br>
&lt;/man close&gt;<br>
<br>
<br>
<br>
<br>
I assume it is expected but undesirable behavior: couldn&#39;t we check for<br>
quota space left, and avoid write behind if we aregoing to hit the<br>
barrier?<br>
<br>
--<br>
Emmanuel Dreyfus<br>
<a href="http://hcpnet.free.fr/pubz" target="_blank">http://hcpnet.free.fr/pubz</a><br>
<a href="mailto:manu@netbsd.org">manu@netbsd.org</a><br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
<br>
<br>
--<br>
Raghavendra G<br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a><br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Raghavendra G<br>
</div></div>