<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 9:14 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Anand Avati <<a href="mailto:avati@gluster.org">avati@gluster.org</a>> wrote:<br>
<br>
> In meta all file sizes are 0 (since the contents of the inode are generated<br>
> dynamically on open()/read(), size is unknown during lookup() -- just like<br>
> /proc). And therefore all meta file open()s are forced into direct_io_mode (<br>
> <a href="http://review.gluster.org/7506" target="_blank">http://review.gluster.org/7506</a>) so that read() requests are sent straight<br>
> to FUSE/glusterfs bypassing VFS (size is ignored etc.)<br>
<br>
</div>I found the code in the kernel that skips the read if it is beyond known<br>
file size. Hence I guess the idea is that on lookup of a file with a<br>
size equal to 0, a special handling should be done so that reads happens<br>
anyway.</blockquote><div><br></div><div>If FUSE implements proper direct_io semantics (somewhat like how O_DIRECT flag is handled) and allows the mode to be enabled by the FS in open_cbk, then I guess such a special handling of 0-byte need not be necessary? At least it hasn't been necessary in Linux FUSE implementation.<br>
</div><div><br></div></div></div></div>