At 07:51 24.09.2007 -0400, Matt McCutchen wrote:
>On 9/24/07, Fabian Cenedese <[EMAIL PROTECTED]> wrote:
>> I was wondering if it would be possible to add a switch (probably coupled
>> to -v(+) ) that would report the number of matched blocks per file. Maybe
>> even with the offset of the block.
>
On 9/24/07, Fabian Cenedese <[EMAIL PROTECTED]> wrote:
> I was wondering if it would be possible to add a switch (probably coupled
> to -v(+) ) that would report the number of matched blocks per file. Maybe
> even with the offset of the block.
Rsync already lists all matched blocks by their offset
>Not necessarily. Depending on how pg_dump works, it could be that
>small changes to the database are resulting in unnecessarily large
>changes to the dump. Make sure you are using the uncompressed format
>because most compression algorithms defeat the delta-transfer
>algorithm almost completely
On Sun, 2007-09-23 at 17:46 -0400, Matt McCutchen wrote:
> On 9/23/07, WebTent <[EMAIL PROTECTED]> wrote:
> Not necessarily. Depending on how pg_dump works, it could be that
> small changes to the database are resulting in unnecessarily large
> changes to the dump. Make sure you are using the unc
On 9/23/07, WebTent <[EMAIL PROTECTED]> wrote:
> Well, I am getting matched data, but it just doesn't seem to be matching
> very much considering the small change in file size. I tested one dump
> after another rsyncing in between dumps and got very little matched
> data :(
> mx1# pg_dump -Fc -Upg
On Sun, 2007-09-23 at 12:09 -0400, Matt McCutchen wrote:
> On 9/23/07, Robert Fitzpatrick <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-09-23 at 00:56 -0400, Matt McCutchen wrote:
> > > Either the delta transfer algorithm is not being used due to a
> > > misconfiguration, or the pgsql backups are cha
On 9/23/07, Robert Fitzpatrick <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-09-23 at 00:56 -0400, Matt McCutchen wrote:
> > Either the delta transfer algorithm is not being used due to a
> > misconfiguration, or the pgsql backups are changing in a perverse way
> > that prevents it from matching any da
l
> that affect delta copies?
No, rsync will match as much data as it can regardless of the relative
sizes of the source and old destination files.
Matt
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
ook and realize that
my sql backup is actually smaller some days than the destination, will
that affect delta copies? This is because the db is a mail cache and
items expire each night and get purged from the database, then vacuumed.
So, the size will relatively stay the same, but will fluctuate
On 9/22/07, Robert Fitzpatrick <[EMAIL PROTECTED]> wrote:
> Are you saying that rsync knows
> the difference and will enable/disable delta transfers depending on
> whether local or not?
Yes.
> However, again, I get the same result doing remote
> transfers.
Either the delta transfer algorithm is
On Sat, 2007-09-22 at 20:00 -0400, Matt McCutchen wrote:
> On 9/22/07, Robert Fitzpatrick <[EMAIL PROTECTED]> wrote:
> Delta transfers reduce network traffic between the sending and
> receiving rsync processes at the cost of some extra CPU time and disk
> I/O (e.g., the receiver has to read the old
file, but I can't imagine why you would want to do
this unless you are testing to see how much traffic reduction delta
transfers would achieve.
> Also, does the match data bytes show the amount
> matched when making delta copies, I assume?
Yes. More precisely, it shows the amount that
Unix servers. So, I'd like this to happen for me,
thanks for any help...Also, does the match data bytes show the amount
matched when making delta copies, I assume? This seems to be the case as
the above shows zero and I see almost the same amount of byes here in my
Windows transfer.
--
Robe
13 matches
Mail list logo
