[Gluster-devel] Reporting on OS X bricks

Dennis Schafroth dennis at schafroth.dk
Sat Feb 28 11:40:00 UTC 2015


I am testing glusterfs on OS X (yosemite) as bricks  and this does not go well with symbolic links due to what I believe is missing support for hardlinking to a symlink (not its target) in HFS+. 

So when doing a symlink to a file like:

$ touch from_file
$ ln -s from_file to_symlink

I am getting:

[2015-02-25 07:08:03.092538] W [posix-handle.c:711:posix_handle_hard] 0-repl-posix: link /export/data/brick1/symlink -> /export/data/brick1/.glusterfs/0f/eb/0feb5989-30c9-4f09-812a-dfbfc9e9956a failed (Operation not supported)
[2015-02-26 22:16:26.074432] E [posix.c:1796:posix_symlink] 0-repl-posix: setting gfid on /export/data/brick1/to_symlink failed

Which is what the linkat describes: if not giving AT_SYMLINK_FOLLOW flag some file system will report this. 

I haven’t tried with another filesystem yet, but OpenZFS is a possibility. I was just wondering if anyone already tried that? 

Just for the fun of it I build without using the linkat but the regular link. Now the link above succeed but it will be a hardlink to the target of the symlink. 

So the attempt to get the READLINK fails: 

[2015-02-28 10:20:27.934944] W [posix-handle.c:730:posix_handle_hard] 0-repl-posix: mismatching ino/dev between file /export/data/brick1/to_symlink (28617302/16777221) and handle /export/data/brick1/.glusterfs/04/87/048787fc-0d99-4927-8ef1-357f56fe84ae (28141430/16777221)
[2015-02-28 10:20:27.935036] E [posix.c:1796:posix_symlink] 0-repl-posix: setting gfid on /export/data/brick1/to_symlink failed
[2015-02-28 10:20:30.225177] E [posix.c:1038:posix_readlink] 0-repl-posix: readlink on /export/data/brick1/.glusterfs/04/87/048787fc-0d99-4927-8ef1-357f56fe84ae failed: Invalid argument
[2015-02-28 10:20:30.225244] I [server-rpc-fops.c:1641:server_readlink_cbk] 0-repl-server: 139132: READLINK /to_symlink (048787fc-0d99-4927-8ef1-357f56fe84ae) ==> (Invalid argument)

This fails because glusterfs tries to readlink on a regular file. I will try to analyse a bit more to see if there could be a work-around


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150228/c52123d3/attachment-0001.html>

More information about the Gluster-devel mailing list