Author: Christoph Litauer <litauer AT uni-koblenz DOT de>
Date: Wed, 02 Jul 2008 16:19:06 +0200
Christoph Litauer schrieb: Well, as nobody could help me so far (even the xfs mailing list is very slient ...), let's get a step further: My filesystem for backuppc data now contains about 160 millio
Well, as nobody could help me so far (even the xfs mailing list is very slient ...), let's get a step further: My filesystem for backuppc data now contains about 160 million inodes. bonnie++ tells m
Author: Christoph Litauer <litauer AT uni-koblenz DOT de>
Date: Thu, 03 Jul 2008 10:29:55 +0200
dan schrieb: Dan, do you have bonnie++ installed? Would you please benchmark your filesystems with: bonnie++ -u root -f -n 10:0:0:1000 -s0 And post the file creation results? Thanks a lot! Additional
Author: Craig Barratt <cbarratt AT users.sourceforge DOT net>
Date: Tue, 08 Jul 2008 02:00:24 -0700
Thanks for the interesting analysis. dirCache is called 5063 times, so that is the number of directories. But BackupPC::Attrib::read is called 30255 times, so it appears that 6 backups are being merg
Author: Christoph Litauer <litauer AT uni-koblenz DOT de>
Date: Mon, 23 Jun 2008 13:48:07 +0200
Hi, some time ago I asked the same question but didn't get an answer. As deletion of incremental dumps is _really_ slow on my server, I try again: If I take a look on the structure of incrementals, I
Author: Craig Barratt <cbarratt AT users.sourceforge DOT net>
Date: Mon, 23 Jun 2008 23:05:45 -0700
Yes - the directory structure needs to be complete, even for an incremental. The storage used should be small. Craig -- Check out the new SourceForge.net Marketplace. It's the best place to buy or se
Author: Christoph Litauer <litauer AT uni-koblenz DOT de>
Date: Tue, 24 Jun 2008 17:21:56 +0200
Craig Barratt schrieb: Craig, can you explain why, please? You're right: The storage amount is very small. But one can get _very_ large directory structures on the backup filesystem. My BackupPC volu
Author: Adam Goryachev <mailinglists AT websitemanagers.com DOT au>
Date: Wed, 25 Jun 2008 02:16:27 +1000
I don't want to get into a war about filesystem formats, but perhaps this is a valid data point for XFS. I don't know about other filesystem types either... You might like to check out/talk to some X
For comparison's sake... this is on a 4 disk software RAID5. [root@tendo .RAID]# find . -type d | wc -l 1164630 [root@tendo .RAID]# cd tmp [root@tendo tmp]# pwd /.RAID/tmp [root@tendo tmp]# time for
Author: Adam Goryachev <mailinglists AT websitemanagers.com DOT au>
Date: Thu, 26 Jun 2008 11:39:45 +1000
Using reiserfs I get these results: keep:/var/lib/backuppc/tmp# time for i in `seq 1 10000`; do mkdir $i; done real 0m22.765s user 0m7.192s sys 0m15.497s /dev/hdc1 on /var/lib/backuppc type reiserfs
Author: Christoph Litauer <litauer AT uni-koblenz DOT de>
Date: Thu, 26 Jun 2008 14:59:20 +0200
Adam Goryachev schrieb: Thanks a lot Adam! In the meantime I discussed my problem on the xfs mailing list. We are not finished yet, but adding mount option "nobarrier" reduced my performance problems
Author: Les Mikesell <les AT futuresource DOT com>
Date: Thu, 26 Jun 2008 08:26:21 -0500
Filesystem optimization that tries to allocate files or inodes near their containing directory isn't likely to help with backuppc since most directory entries end up being hard links to content in so
Author: Christoph Litauer <litauer AT uni-koblenz DOT de>
Date: Thu, 26 Jun 2008 16:01:51 +0200
Les Mikesell schrieb: Full acknowledge! xfs supports a mount option inode64 which - according to the xfs mailing list - would avoid the search for "near inodes". But inode64 is only available on 64 b
Author: Tino Schwarze <backuppc.lists AT tisc DOT de>
Date: Thu, 26 Jun 2008 16:06:09 +0200
<5>Filesystem "dm-1": Disabling barriers, not supported by the underlying device during booting the system... I once thought it would be sensible to have larger directory blocks, but then, a lot of t
Author: Christoph Litauer <litauer AT uni-koblenz DOT de>
Date: Fri, 27 Jun 2008 09:19:24 +0200
Christoph Litauer schrieb: Well ... this was the good news ... ... now the bad ones ... This morning, 2 backup processes were still running. strace'ing one client process, one can see that rsync is w