Hi,
I am working on a replication tool for lustre filesystems.
We have introduced a mechanism for getting the changes that have been
made to a lustre filesystem - similar to inotify. We call this
mechanism, changelogs.
For performing replication, we open the source file using its 'file
identifie
Hello,
I routinely mirror databases with many directories, each containing
20,000 file or more. Many of the older directories rarely change and
are identical on the mirror(s), but rsync still sends over the file list
from all directories every time. This results in lists containing
hundreds
Jamie Lokier wrote:
> David Howe wrote:
> > Jamie Lokier wrote:
> > I am less worried about individual file renames and/or "missing" the
> > opportunity to diff a large file that has been both moved and updated,
> > than having to resync multiple gigs of stuff over a slow link, because
> > some use
David Howe wrote:
> Jamie Lokier wrote:
> I am less worried about individual file renames and/or "missing" the
> opportunity to diff a large file that has been both moved and updated,
> than having to resync multiple gigs of stuff over a slow link, because
> some user renamed a directory.
An appro
Jamie Lokier wrote:
> There are methods to perform efficient updates of large numbers of
> files and a large amount of data, across simultaneous renames, copies
> and edits. But that is the realm of "similarity detection indexing",
> which is beyond the scope of rsync. At least with the present d
N.J. van der Horn (Nico) wrote:
> >But you need to verify and update the DB contents - which requires
> >stat on all the files mentioned in the DB. In other words you might
> >have to scan everything :-)
> >
> This already takes place while Rsync does its job, so it has not to be
> done separat
Jamie Lokier schreef:
N.J. van der Horn (Nico) wrote:
The highest speed and efficiency is to only observe time and size as
then just a stat-call is needed. But in more complex situations you
have to take also the checksum, inode-number, etc into account. In
previous posts there were many
N.J. van der Horn (Nico) wrote:
> The highest speed and efficiency is to only observe time and size as
> then just a stat-call is needed. But in more complex situations you
> have to take also the checksum, inode-number, etc into account. In
> previous posts there were many ideas to cope with thi
The highest speed and efficiency is to only observe time and size as
then just a stat-call is needed.
But in more complex situations you have to take also the checksum,
inode-number, etc into account.
In previous posts there were many ideas to cope with this. As rsync is
state-less regarding the
