It's just need to start clsync-process when container SoĪndrew Savchenko proposed to run one clsync-instance per container. So I've started to write code forīi-directional syncing, however it's no time to complete it :(. " /srv/nodes//containers/")Īnd syncing every directory only in one direction. Well, in this case I with my colleagues were using separate directories forĮvery node of cluster (e.g. Get sync-loop [file-update on A causes file-update on B causes file-update Just run clsync to sync containers to neighboring node on both of them, you'll In this case you have to sync containers in both directions. LXC and trying to replicate containers between two servers (to make failover However let's solve next hypothetical problem. I've started to implement support of bi-directional syncing with using R /dev/stdin -Mdirect -r1 -ignore-failures -t1 -w1 -Smake - build Printf "%s\n" " f.c$" "-f" | clsync -have-recursive-sync -W. Some distributions already have clsync supported in the main repo: UPD: Starting with kernels 5.1 we will be able to use fanotify for all events ) 4 - Installing "inotify", leaving the code for "fanotify" in the safety. The program, like "directory creation" or "file deletion". However I encountered the problem, thatįanotify was unable to catch some important events at the moment of writing It's said that fanotify is much better than inotify. Incron/csync2/etc in our HPC-clusters for syncing /etc/įiles and running post-scripts. So there it is :)Īlso clsync had been used for some other tiny tasks, like to replace "lsyncd" to realize that we could've already write a new tool Long story short: "lsyncd" - is a good and useful utility, just did notįit to our needs well enough. It doesn't support kqueue/bsm (we also had a FreeBSD-based system).Sometimes, it's too complex in configuration for our situation (not flexible.It's a little buggy (it crashed on our cases).It requires LUA libs, that cannot be easily installed to few.It's more difficult to maintain the code with ordinary sysadmin.There a lot of problems connected with it, The best known (for me) replacement for this utility is "lsyncd", however: To do backups we also tried a lot of different solution, and again I was have Was have to write own utility for this purpose. However all of this solutions doesn't satisfy me, so I Started to write the utility we were using "lsyncd", "ceph" and Storage", "incron perl rsync", "inosync", "lsyncd" and so on. Rsync by cron", "glusterfs", "ocfs2 over drbd", "shared replicated external To do a HA cluster I've tried a lot of different solutions, like "simple This utility has been written for two purposes: Written on "LUA" and may be used for similar purposes. So I called itĬlsync that should be interpreted as "lsync but on c" due to "lsyncd" that "Runtime Sync" or "Live Sync" but rtsync is a name of some corporation and Have to temporary fallback to inotify, so I decided that the best name is I faced with some problems in fanotify (see "inotify vs fanotify"). Then I started to intensively write the program and Then I was suggested to use fanotify instead of inotify and utility has been Source is freely available on the project page linked below.Why clsync? The first name of the utility was insync (due to inotify) but Users wishing to contribute to this project should fork it and send a pull request. It should not be called by the user directly. The psd-overlay-helper script is used internally to enable the usage of the overlay file system. Additionally, psd features several crash recovery features. This is accomplished by an innovative use of rsync to maintain synchronization between a tmpfs copy and media-bound backup of the browser profile/profiles. Profile-sync-daemon (psd) is a tiny pseudo-daemon designed to manage browser profile/profiles in tmpfs and to periodically sync back to the physical disc (HDD/SSD). Script to use overlay file system for profile-sync-daemon.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |