<br><div class="gmail_quote">On Wed, Feb 13, 2013 at 3:44 PM, Theodore Ts&#39;o <span dir="ltr">&lt;<a href="mailto:tytso@mit.edu" target="_blank">tytso@mit.edu</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I suspect this would seriously screw over Gluster, though, and this<br>
wouldn&#39;t be a solution for NFSv3, since NFS needs long-lived directory<br>
cookies, and not the short-lived cookies which is all POSIX/SuSv3 guarantees.<br></blockquote><div> </div><div><div>Actually this would work just fine with Gluster. Except in the case of gluster-NFS, the native client is only acting like a router/proxy of syscalls to the backend system. A directory opened by an application will have a matching directory fd opened on ext4, and readdir from an app will be translated into readdir on the matching fd on ext4. So the app-on-glusterfs and glusterfsd-on-ext4 are essentially &quot;moving in tandem&quot;. As long as the offs^H^H^H^H cookies do not overflow in the transformation, Gluster would not have a problem.</div>
<div><br></div><div>However Gluster-NFS (and NFS in general, too) will break, as we opendir/closedir potentially on every request.</div></div><div><br></div><div>Avati</div></div>