The problem is easily reproduced by creating a volume with a couple of files and a symlink to a non existing file, and then exporting it and mounting it with unify starting with an empty namespace. Only part of the files will be created in the namespace (all those that readdir() returned before the dangling symlink). The problem can be solved with the patch posted at http://lists.gnu.org/archive/html/gluster-devel/2009-01/msg00173.html . It only affects version 2.0 because in 1.3 the return value of the chown that fails is not checked. Filipe On Fri, Jan 16, 2009 at 10:06, Anand Avati <avati at zresearch.com> wrote: >> I *think* (and I'm sure Anand will correct me if I'm wrong), in the case of >> a single brick, gluster doesn't care much about it's extended attributes, >> but once another brick/node is involved (in unify or replicate), then the >> extended attributes become important. >> >> pre-existing data is generally without Xattr's and so this causes confusion. >> My guess is, adding the extended attributes (which happens when you copy the >> file into the gluster mountpoint) would solve the problem. > > This is generally true, but in this situation he is using unify (which > does not use xattrs on the backend) and most of the other cases, if > the xattr is missing, the appropriate self heal will atleast try to > set the most sensible xattr values when the file is first looked up. > > Avati >
