Hi Jan, This means, the 'trusted.gfid' xattr (which is very much required by the glusterfs to work fine and is sort of inode number of a file in regular fs) is missing for that particular folder. One way to fix it is by below steps on other nodes where you don't have any logs: sh# getfattr -d -m trusted.gfid <some folder> <output> on the node which has issue of logs: sh# setfattr -n trusted.gfid -v <value got in other node> <some folder> This should solve the issue. This state is mostly reached by not having this one machine ready before having a client machine mounting the volume and accessing these folders. Regards, Amar On Sat, May 21, 2011 at 4:23 AM, Jan Wynholds <jwynholds at 510systems.com>wrote: > Hello: > > We have a 8 node gluster setup here. Some of the nodes were running > 3.0.7 and 3.0.8. One of the nodes has an xfs filesystem (which is the > only difference between the rest which are ext4). > > On the xfs (that was also previously running 3.0.7 and 8), grows logs > at an alarming rate (gigs a day). > > The logs are filled with errors such as: > > [2011-05-20 15:10:46.630875] E [posix.c:438:posix_lookup] > 0-store1-posix: lstat on [some folder] failed: No data available > > After looking through the documentation, and traffic on the mailing > lists, I have come up empty on an explanation. > > Any insight would be most appreciated. > > --cheers > > jan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://gluster.org/pipermail/gluster-users/attachments/20110524/2d1ec421/attachment.htm>
