[Gluster-devel] how does meta xlator work?

[Anand Avati]

My guess would be that direct_io_mode works differently on *BSD. In Linux
(and it appears in OS/X as well), the VFS takes hint from the file size
(returned in lookup/stat) to limit itself from not read()ing beyond that
offset. So if a file size is returned 0 in lookup, read() is never received
even by FUSE.

In meta all file sizes are 0 (since the contents of the inode are generated
dynamically on open()/read(), size is unknown during lookup() -- just like
/proc). And therefore all meta file open()s are forced into direct_io_mode (
http://review.gluster.org/7506) so that read() requests are sent straight
to FUSE/glusterfs bypassing VFS (size is ignored etc.)

So my guess would be to inspect how direct_io_mode works in those FUSE
implementations first. It is unlikely to be any other issue.

Thanks


On Sun, Aug 10, 2014 at 9:56 PM, Harshavardhana <harsha at harshavardhana.net>
wrote:

> > I am working on tests/basic/meta.t on NetBSD
> > It fails because .meta/frames is empty, like all files in .meta. A quick
> > investigation in source code shows that the function responsible for
> > filling the code (frames_file_fill) is never called.
> >
>
> Same experience here.
>
> It does work on OSX, but does not work on FreeBSD for similar reasons
> haven't figured it out yet what is causing the issue.
>
> --
> Religious confuse piety with mere ritual, the virtuous confuse
> regulation with outcomes
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140811/04e472da/attachment.html>