With the changes in glusterfs to bring in 'gfid' based inode number management, the extended attribute support is mandatory in backend disk.<div><br></div><div>Earlier versions (ie, till 3.0.x branch) can work without extended attributes with 'option mandate-xattr off' option in storage/posix volume in volume file.</div>
<div><br></div><div>But considering you are using replicate with glusterfs's consistency check xattrs being required by replicate, it would not work for you in practical use case.</div><div><br></div><div>Regards,</div>
<div>Amar<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
I am trying to setup a replicated volume to serve (in a load-balanced<br>
setup) static content. Since we are talking about small sized files<br>
(thumbnails) that do not take too much space, one ideea is to set that<br>
up in RAM (using /dev/shm mountpoint on CentOS).<br>
<br>
The main problem is that if I define a replicated volume using<br>
glusterfs, and I have the export directory for each brick on /dev/shm<br>
(eg. gluster volume create thumbs replica 2<br>
192.168.111.1:/dev/shm/thumbs 192.168.111.2:/dev/shm/thumbs) and start<br>
the volume, the volume is up according to gluster volume info, but I<br>
can't access it from a native client.<br>
<br>
If I try to do that, I get Transport Endpoint is not connected on client<br>
and on bricks I get:<br>
<br>
Aug 23 09:28:55 www-widget01 GlusterFS[24633]: [2011-08-23<br>
09:28:55.210740] C [posix.c:4622:init] 0-thumbs-posix: Extended<br>
attribute not supported, exiting.<br>
<br>
It is paramount that the underlying FS supports xattr? If not, is there<br>
a way to inhibit this dependency and use a volume created on /dev/shm?<br>
<br>
Do I have any other options that would work with an export directory<br>
located on a RAM based FS and not a disk one?<br>
<br>
Best regards,<br>
<br>
Sandu Mihai<br></blockquote></div></div>