Re: parallel file create rates (+high latency)

[Daire Byrne <daire@dneg.com>]

On Tue, 25 Jan 2022 at 23:01, Patrick Goetz <pgoetz@math.utexas.edu> wrote:
> On 1/25/22 16:41, Daire Byrne wrote:
> > On Tue, 25 Jan 2022 at 22:11, Patrick Goetz <pgoetz@math.utexas.edu> 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