[BackupPC-users] Parity (par2) command running on archives even though s

Hello!

I have set up a couple of BackupPC 3.2.1 hosts (using the EPEL package). For some of my archives, the size is too large for par2 to complete in 1200 minutes (the default limit for archvies without response) and for some reason, BackupPC does not see the fact that par2 is doing something, even though it seems to spew enough stuff into my logs... So, for those hosts, I have the parity set to 0.

In the past, with parity set to 0, the parity command was not run. However, on these newer servers, I get this:

Executing: /usr/share/BackupPC/bin/BackupPC_archiveHost /usr/share/BackupPC/bin/BackupPC_tarCreate /usr/bin/split /usr/bin/par2 intake 30 /usr/bin/gzip .gz 0000000 /data/archive 0 *
Xfer PIDs are now 1720
Writing tar archive for host intake, backup #30 to output file /data/archive/intake.30.tar.gz
Done: 91664 files, 60654476096 bytes, 6404 dirs, 1747 specials, 0 errors
Running /usr/bin/par2 to create parity files
par2cmdline version 0.4, Copyright (C) 2003 Peter Brian Clements.
Modifications for concurrent processing, Unicode support, and hierarchial
directory support are Copyright (c) 2007-2009 Vincent Tan.
Concurrent processing utilises Intel Thread Building Blocks 2.0,
Copyright (c) 2007-2008 Intel Corp.
Executing using the 64-bit x86 (AMD64) instruction set.

par2cmdline comes with ABSOLUTELY NO WARRANTY.

This is free software, and you are welcome to redistribute it and/or modify
it under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version. See COPYING for details.

Processing checksums and Reed-Solomon data concurrently.
Block size: 24046376
Source file count: 1
Source block count: 2000
Redundancy: 0%
Recovery block count: 0
Recovery file count: 0

Opening: intake.30.tar.gz
<Snipped ton of ouput from 0% to 100.0%>
Writing verification packets
Done

As you can see, the parity command is being run. (And par2 is wasting a *lot* of electrons and hard drive wear doing *something* for a very log time, even though in the end it doesn't write any parity files!).

This did not happen with 3.1: with 3.1, the parity command is never run (AFAICT: I'm using the save version of par2, so that won't have changed).

Why does BackupPC run the parity command if I've told it not to by passing it a 0? And how do I return to the 3.1 behavior? According to the documentation, setting it to 0 should disable it, not cause it to run with a parameter of 0... And if for some reason we would *want* the parity to run with a parity of 0, could we have a parameter that disables it? Maybe -1? How do you calculate *negative* parity! :)

While we're on the subject: what could I do to get BackupPC to realize that par2 is doing its thing even if it doesn't think it's seeing output from the command? It's certainly spewing plenty of things out while it's working: it outputs something for every 0.1% of output it processes... Then I would be able to generate parity for things that take more than 1200 minutes if I wanted to. (Yes, I know I can change the limit. I'd like to: to much *shorter*, by making BackupPC aware that the parity process is still working!)

Tim Massey


Out of the Box Solutions, Inc. Creative IT Solutions Made Simple! http://www.OutOfTheBoxSolutions.com tmassey AT obscorp DOT com		22108 Harper Ave. St. Clair Shores, MI 48080 Office: (800)750-4OBS (4627) Cell: (586)945-8796

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

[BackupPC-users] Parity (par2) command running on archives even though set to 0