Re: [rdiff-backup-users] 1.2.8 vs 1.3.3
Greg, it seems this mailing list has not seen any message of the currently responsible project leader for a long time. I agree in thinking that 1.3.3 is the best and most stable version so far, It has still bugs though. Cheers David. > -Ursprüngliche Nachricht- > Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org [mailto:rdiff- > backup-users-bounces+mail=dkriesel@nongnu.org] Im Auftrag von Greg > Troxel > Gesendet: Montag, 31. Oktober 2011 19:07 > An: rdiff-backup-users@nongnu.org > Betreff: [rdiff-backup-users] 1.2.8 vs 1.3.3 > > > On the web page, 1.2.8 is listed as stable and 1.3.3 as > development/unstable. But, it's been a long time. > > So: > > are there changes since 1.3.3? > if so, should there be a new release? > > is anyone who has project admin permission around? > > is 1.3.3 considered stable? As in, should I upgrade the entry in > pkgsrc to 1.3.3 from 1.2.8 so users just get 1.3.3 (which is really: > is it in the best interest of a user who doesn't know enough to choose > to be handed 1.2.8 or 1.3.3?) > > Thanks, > Greg ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
[rdiff-backup-users] 1.2.8 vs 1.3.3
On the web page, 1.2.8 is listed as stable and 1.3.3 as development/unstable. But, it's been a long time. So: are there changes since 1.3.3? if so, should there be a new release? is anyone who has project admin permission around? is 1.3.3 considered stable? As in, should I upgrade the entry in pkgsrc to 1.3.3 from 1.2.8 so users just get 1.3.3 (which is really: is it in the best interest of a user who doesn't know enough to choose to be handed 1.2.8 or 1.3.3?) Thanks, Greg pgpVnL4vS0sK2.pgp Description: PGP signature ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
[rdiff-backup-users] excessive fsync(2)
With 1.2.8 on NetBSD, I was seeing insanely long backup times, as in over a week for a 300G filesystem on which little had changed. With ktrace, I found the problem was that fsync() was called incredibly often (per file checked?) and my backup drive was mounted with WAPBL (metadata journaling), and fsync causes the log to be written, which causes a cache flush on the drive. fsync was taking 3/4s most of the time. I rebuilt rdiff-backup with the fsync call commented out and then it ran reasonably quickly). On another machine with two differences: disk not mounted with wapbl and rdiff-backup client remote and accessing it over ssh, either of which might matter, backups go reasonably quickly as well. One can argue that this implementation of fsync (cache flush, rather than some sort of barrier) is inefficient, but fsync cannot properly return until all the file's data and metadata is safely on disk, so it's intrinscially a non-streaming expensive operation. Can anyone explain why rdiff-backup is doing fsyncs so often? I would expect the plan to be to write all the files and record the files-written log, and then at the end sync(2) it all (and then wait, since sync doesn't wait to completion), and then to remove the backup-in-progress flag. with the regress-dirty strategy, that kind of makes the whole thing a transaction. Thanks, Greg pgpXnunzOUfd3.pgp Description: PGP signature ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] [from] Re: Memory usage during regressions
On 28/10/2011 11:03, john wrote: Hi The same problem as described here strucked me, too: When regressing a backup, rdiff-backup starts instantly consuming memory at quite a high rate, until it reaches 3GB. Then it dies with a memory allocation error, because it is running on a 32bit system. As this means that I cannot make any new backups now, without starting from scratch, I searched quite a while for a solution to this. But only found this mailing list thread. Does this mean it is a rare error condition? The system to backup is not that big: 2,2 Million files, 400GB. Any hints for debugging? I tested rdiff-backup V1.2.8-r1 and V1.3.3. cu John How much space is there in your /tmp folder? Try specifying a different tmp folder with --local-temp or --remote-temp (i.e. one with massive storage available). Or try increasing the size of your swap location? (rdiff-backup is supposed to use temp folders as specified here under 'tempdir' but I think it doesn't follow this logic, or at least not reliably. However forcing a specific temp location with --local-temp or --remote-temp does seem to work.) Dominic ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
