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
_______________________________________________
Gluster-users mailing list
[email protected]
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
