"Now I am leaning towards git based versioning. Integrate git into GlusterFS to track changes on specified events (timer, file-close, dir-tree-modify..). We may not do this via translator interface, but through the newly proposed simple event/timer interface. " I am not sure I would like that. Our idea is to make the previous versions (read-only!) available to the end-users through a separate mount-point, taking file permissions into account. I am not sure if that is at all possible when they live inside a git repository. (disclaimer: I do not know the inner workings of glusterfs nor translators) I would think making it part (of the receiving part) of geo-replicator translator would be ideal because it knows what is going on. If a file /a/b/c is updated it's previous version could be stored as /pre/a/b/c.<datetime> or /pre/<datetime>/a/b/c. If the previous versions live on the same file-system you could even play with inodes to keep only the previous versions of blocks. This would make it very space efficient (sort of file based snapshotting). I do agree that using git makes it more modular and independent of the geo-replicator translator. I am also curious how you would handle multiple writes in a short time to the same file without ending up with an equal amount of previous versions. Also, I can't find the note you are referring to. Could you please make a feature wiki page using the template? Fred
