Christoph writes:
> 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 me that this filesystem is able to create 1000-4000
> inodes per second.
dan schrieb:
> just for reference:
>
> time for i in `seq 1 1`; do mkdir $i; done
>
> ext3
> real0m15.536s
> user0m7.764s
> sys0m6.108s
> bonnie++
> xfs
> real0m14.365s
> user0m7.856s
> sys0m6.148s
>
> reiserfs
> real0m13.679s
> user0m8.053s
> sys0m6.024s
just for reference:
time for i in `seq 1 1`; do mkdir $i; done
ext3
real0m15.536s
user0m7.764s
sys0m6.108s
bonnie++
xfs
real0m14.365s
user0m7.856s
sys0m6.148s
reiserfs
real0m13.679s
user0m8.053s
sys0m6.024s
On Wed, Jul 2, 2008 at 8:19 AM, Christoph Litau
Christoph Litauer schrieb:
> Christoph Litauer 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 significantly. I am still in contact to clarify if
>
Christoph Litauer 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 significantly. I am still in contact to clarify if
> it's possible to optimize the us
On Thu, Jun 26, 2008 at 02:59:20PM +0200, Christoph Litauer wrote:
> > If I take a look on the structure of incrementals, I can see lots of
> > empty directories. It seems as if the whole directory structure of the
> > backup-source is kind of "duplicated" to the backup disk - although
Les Mikesell schrieb:
> Christoph Litauer wrote:
>>>
>> 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 significantly. I am still in contact to clarify
>> if i
Christoph Litauer wrote:
>>
> 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 significantly. I am still in contact to clarify if
> it's possible to optimize the
Adam Goryachev schrieb:
> Adam Goryachev wrote:
>> Christoph Litauer wrote:
>>> Craig Barratt schrieb:
Christoph writes:
> If I take a look on the structure of incrementals, I can see lots of
> empty directories. It seems as if the whole directory structure of the
> backup-sou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adam Goryachev wrote:
> Christoph Litauer wrote:
>> Craig Barratt schrieb:
>>> Christoph writes:
>>>
If I take a look on the structure of incrementals, I can see lots of
empty directories. It seems as if the whole directory structure of the
>
> 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 XFS experts, and see what they
> say about your very slow performance There may be som
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Litauer wrote:
> Craig Barratt schrieb:
>> Christoph writes:
>>
>>> If I take a look on the structure of incrementals, I can see lots of
>>> empty directories. It seems as if the whole directory structure of the
>>> backup-source is kind of "
Craig Barratt schrieb:
> Christoph writes:
>
>> If I take a look on the structure of incrementals, I can see lots of
>> empty directories. It seems as if the whole directory structure of the
>> backup-source is kind of "duplicated" to the backup disk - although most
>> of the directories (and the
Christoph writes:
> If I take a look on the structure of incrementals, I can see lots of
> empty directories. It seems as if the whole directory structure of the
> backup-source is kind of "duplicated" to the backup disk - although most
> of the directories (and the files in them) are unchanged.
>
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 can see lots of
empty directories. It seems as if the whole directory structure of the
backup-
15 matches
Mail list logo
