<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 14, 2014 at 9:18 AM, Emmanuel Dreyfus <span dir="ltr"><<a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">Vijay Bellur <<a href="mailto:vbellur@redhat.com">vbellur@redhat.com</a>> wrote:<br>
<br>
> You would need to set features.soft-timeout and features.hard-timeout<br>
> values to 0 when testing with lower values of directory quota.<br>
<br>
</span>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></blockquote><div><br></div><div>It happens on other environments too. Applications receive success for writes and writes wouldn'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></div><div>This behaviour is posix-conformant. From man 2 close,<br><br></div><div><man 2 close><br><br></div><div> 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></div><div></man close><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>
I assume it is expected but undesirable behavior: couldn't we check for<br>
quota space left, and avoid write behind if we aregoing to hit the<br>
barrier?<br>
<span class=""><font color="#888888"><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>
</font></span><div class=""><div class="h5">_______________________________________________<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>