On Tue, 25 Jan 2022 at 23:01, Patrick Goetz <pgoetz@xxxxxxxxxxxxxxx> wrote: > On 1/25/22 16:41, Daire Byrne wrote: > > On Tue, 25 Jan 2022 at 22:11, Patrick Goetz <pgoetz@xxxxxxxxxxxxxxx> wrote: > Thanks for this suggestion! This option didn't even occur to me. The > only downside is that this server gets really busy during image > processing, so I'm a bit worried about loading it down with dozens of > simultaneous rsync processes. Also, the biggest performance problem in > this system (which includes multiple GPU-laden workstations and 2 other > NFS servers) is always I/O bottlenecks. I suppose the solution is to > nice all the rsync processes to 19. Yea, that's always the problem with backups - when do you slow down production because backups are more important? :) You could also have another NFS client close (latency) to the server which would free CPU but it's hard to limit IO. You can still use rsync+rsyncd for the higher latency hop. > Question: given that I usually run backups from cron, and given that > they can take a long time, how does msrsync avoid stepping on itself? I guess you would need a lockfile or pgrep for a running instance. TBH, I wrote a simpler version of msrsync in bash that was more suited to our environment but the principle is the same. Daire
