I have just tried a re-sync of many GB using the ls -lR and the ls -lR is hanging while the sync happens. In the release notes for 3.0.0 is says In GlusterFS 2.0.x, if self-healing is required e.g. when a failed Replicate server recovered, the first I/O command executed after recovery, such as a 'ls -l', that triggered the self-healing would block until the self-heal operation completed. With v3.0, self-healing is now done in the background. Commands that can trigger self-healing will thus appear more responsive resulting in a better user experience. Replicated VM images also benefit from this because they can continue to run even while the image is self-healed on a failed server. Do i need to configure anything to get this behaviour? Vikas Gorur wrote: > 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 > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
