Sandu Mihai
2011-Aug-23 07:11 UTC
[Gluster-users] Using glusterfs with an export directory on an non-POSIX attr enabled FS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOU1KlAAoJELXw04oLkAtVaPIIAIpaXsUX17LT9AOUQrPaP/AM nRDSktD60t2giX7OY+TKOCDjKP4spmcr//O0uZtJdU1ZVoyYAcCogeexJA8lZNGD YlWsNgQKSQbhLNYH7p3oPU8moQcEk4+SxcJDLBq82qTxTrB4GdD9R5aAo4F21a5+ HYaA/l0cRiwOg5KpL+577LJOIOvQqnYO+OJHhfAltqMO+6AFcrQ7LGVfVPAqMkqY zfoIriMBpC5UV7Niu5juEGJSzGVxGHrjeib5/sVLA5PQCmk1HnsgK29BPlT0r4AS uSLGCwgjILcfKqo/tZDfEoDHUGmMbnN2hXWNxrcCzpGm8+exUHM2/R2VWksvlEc=ctb/ -----END PGP SIGNATURE-----
Amar Tumballi
2011-Aug-25 09:45 UTC
[Gluster-users] Using glusterfs with an export directory on an non-POSIX attr enabled FS
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>