[Gluster-devel] quota

[Raghavendra G]

On Tue, Oct 14, 2014 at 9:18 AM, Emmanuel Dreyfus <manu at netbsd.org> wrote:

> Vijay Bellur <vbellur at redhat.com> wrote:
>
> > You would need to set features.soft-timeout and features.hard-timeout
> > values to 0 when testing with lower values of directory quota.
>
> It works more like expected this way, but there are still oddities: for
> instance once quota is reached, I can still append smal chunk to a file,
> and do it a lot of times.
>
> A few debug printf tell me this is because of write-behind: the writing
> process gets success, then glusterfs attemps to write - and fail. This
> means we silently discard data, which does not looks nice. Is it the
> expected behavior or is it a NetBSD bug?
>

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.

This behaviour is posix-conformant. From man 2 close,

<man 2 close>

 NOTES
       Not  checking  the  return  value of close() is a common but
nevertheless serious programming error.  It is quite possible that errors
on a
       previous write(2) operation are first reported at the final
close().  Not checking the return value when  closing  the  file  may
lead  to
       silent loss of data.  This can especially be observed with NFS and
with disk quota.

       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
       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
       will depend on the disk hardware at this point.)

</man close>


> I assume it is expected but undesirable behavior: couldn't we check for
> quota space left, and avoid write behind if we aregoing to hit the
> barrier?
>
> --
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu at netbsd.org
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20141015/ad4c666e/attachment.html>