<br><div class="gmail_quote"><div class="gmail_quote">2009/9/16 Anand Avati <span dir="ltr"><<a href="mailto:avati@gluster.com" target="_blank">avati@gluster.com</a>></span><div><div></div><div class="h5"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>> No, not really. In fact every other comment about glusterfs(d) reads like<br>
> "this is a standard application regarding the fs, therefore it cannot be<br>
> responsible for problem A or bug B". Now, if it is to be judged as one of many<br>
> applications on the one hand, then it should be able to cope with situations<br>
> that every standard application can cope with either - other applications<br>
> using the same fs.<br>
<br>
</div>glusterfs is a standard application regarding the fs, therefore it<br>
cannot be responsible for problems showing up in the kernel. glusterfs<br>
is not expected to work properly if you modify the backend export<br>
directory directly bypassing the mountpoint. This is the baseline<br>
premise for using glusterfs.<br>
<div><br>
> _The_ advantage of the whole glusterfs concept is exactly that it is _no_ fs<br>
> with a own and special disk layout. It (should) run(s) on top of an existing<br>
> fs that can be used just like a fs may be used - including backup (with rsync<br>
> or whatever), restore and file operations of any kind.<br>
<br>
</div>glusterfs uses a disk based filesystem as its backend. This in no way<br>
implies that it can share the backend with other applications and work<br>
without problems. glusterfs needs _exclusive_ access to this export<br>
directory. That is how it is designed to work. If you backup one<br>
backend, you can restor it only as that very backend. What you are<br>
trying is to do is use one backend as another subvolumes backend. If<br>
you expect copying over the backend by skipping the xattrs, while<br>
modifying those very files from the mountpoint to just work, then the<br>
expectation is improperly set. Please copy in all your content only<br>
from the mountpoint.<br>
<div><br>
> If subvolumes are indeed closed storages then they would be in no way<br>
> different than nbd, enbd, whatever-nbd. For various reasons we don't want<br>
> these solutions.<br>
<br>
</div>GlusterFS is surely not a solution where you can freely modify the<br>
backend directly. For proper operation of the filesystem, the only<br>
supported mode of usage is through the mountpoint. Whatever<br>
modification you do with the backend is done at your own risk.<br>
<font color="#888888"><br>
Avati<br>
</font><div><div></div><div><br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org" target="_blank">Gluster-devel@nongnu.org</a><br>
<a href="http://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">http://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br></div></div></blockquote></div></div><div><br>Stephan,<br>As Avati has tried to make clear, GlusterFS with the cluster/replicate translator relies very heavily on the backend filesystem's support for extended attributes, and these extended attributes are what GlusterFS uses to know if a file is more up to date on one brick over another when performing a self heal.<br>
<br>I feel that you have not read the link <a href="http://www.gluster.com/community/documentation/index.php/Understanding_AFR_Translator" target="_blank">Understanding AFR translator</a>. This link should explain exactly how GlusterFS performs self-heal, and should help you understand its use of extended attributes. There used to be a way to initialise a brick for use with GlusterFS by manually setting the appropriate extended attributes. I do not know if this is still supported.<br>
<br>You are welcome to read the source code for more in depth understanding of the particular extended attributes used by GlusterFS for the replicate translator.<br><br>Don't try bypassing the mountpoint to perform file operations _period_ . You can always have a replicate mountpoint configured on the server (i.e. a client for replicate), as well as the server side. NFS should run on top of this replicate mountpoint. This (poor) graphic may help. Note that everything is running on the same machine:<br>
<br><font face="courier new,monospace">| NFS |<br>------------------<br>|GlusterFS Client|<br>------------------<br>|GlusterFS Server|<br>------------------<br>| POSIX Storage |<br>------------------<br><br><font face="arial,helvetica,sans-serif">Regards,<br>
Michael Cassaniti<br></font></font></div></div>
</div><br>