[Gluster-users] Using glusterfs with an export directory on an non-POSIX attr enabled FS

[Amar Tumballi]

With the changes in glusterfs to bring in 'gfid' based inode number
management, the extended attribute support is mandatory in backend disk.

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.

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.

Regards,
Amar


>
> I am trying to setup a replicated volume to serve (in a load-balanced
> setup) static content. Since we are talking about small sized files
> (thumbnails) that do not take too much space, one ideea is to set that
> up in RAM (using /dev/shm mountpoint on CentOS).
>
> The main problem is that if I define a replicated volume using
> glusterfs, and I have the export directory for each brick on /dev/shm
> (eg. gluster volume create thumbs replica 2
> 192.168.111.1:/dev/shm/thumbs 192.168.111.2:/dev/shm/thumbs) and start
> the volume, the volume is up according to gluster volume info, but I
> can't access it from a native client.
>
> If I try to do that, I get Transport Endpoint is not connected on client
> and on bricks I get:
>
> Aug 23 09:28:55 www-widget01 GlusterFS[24633]: [2011-08-23
> 09:28:55.210740] C [posix.c:4622:init] 0-thumbs-posix: Extended
> attribute not supported, exiting.
>
> It is paramount that the underlying FS supports xattr? If not, is there
> a way to inhibit this dependency and use a volume created on /dev/shm?
>
> Do I have any other options that would work with an export directory
> located on a RAM based FS and not a disk one?
>
> Best regards,
>
> Sandu Mihai
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20110825/4eb8c99b/attachment.html>