Adrian Revill wrote: > Thanks Vikas, > > You were right, i commented out the stat-prefetch section and the sync > now works. Perhaps the glusterfs-volgen should not put it in for raid 1 We'll review this and see if we can tweak stat-prefetch to allow replicate sync's to happen sooner. > So it looks like to make a fully redundant system we need to poll the > client mount points with ls -lR at least at server startup. > For scalability, the servers should run the client mount on itself and > poll itself. > Surely a feature to trigger a full re-sync should be part of the > server daemon, perhaps first client to connect gets a please sync me > message. That's something to think about. I'm not sure if such a re-sync is best done by GlusterFS or by an external tool. > I found a little gotcha with file deletion > > 2 servers running, create a file, and shut down server2, delete the > file and shut down server1. Start server2 and the file reappears, > which is expected, start server1 and the file remains and is synced > back to server1. > This means in case of a server failure, server restarts, the order > that servers are restarted is very important if the un-deletion of > files is an issue. I'll look into this. GlusterFS in general takes a conservative approach and when in doubt prefers to retain data than deleting. > I also found that lsattr does not work with glusterfs > lsattr /mnt/export/ > lsattr: Inappropriate ioctl for device While reading flags on > /mnt/export/t2 lsattr is a tool specific to Ext2/Ext3 filesystems and will not work on other filesystems (be they fuse-based or disk-based like ReiserFS or XFS). Vikas
