xfs
[Top] [All Lists]

Re: Speed of rm compared to reiserfs (slow)

To: Török Edwin <edwintorok@xxxxxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: Speed of rm compared to reiserfs (slow)
From: Török Edwin <edwintorok@xxxxxxxxx>
Date: Fri, 26 Sep 2008 10:41:27 +0300
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=WWHIqeWSMF1MWDVLP7wAYYzgSIrp2lDV20pE+3sTS58=; b=bJyYCj0TWUn7IT+7uX+h4xbqEZcPwBufx4V4R7WeM5o+TAebnhIlXvrI8ViU+mbl+z ozZio1ietYiEl/lzy9Bizf7xm7YUnNsLUDU/2gSb79DKpk4hzlIbaV5DX1VL6Omk0Uxm 4fe7PVnZYMfVZufv+8TIo+9pXjXQTo2yzaLMM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Uzo1iiD1ugcIwCWu7YhogYkZV4aGtMv/rI8l7XwTsuWQFXklhdCshyusyF+q7er8wq B6LR6aamNQw98QbICzdB8+CtxF9zMMadqjj9Fk96XvwWqM80xHt/maBDjyiPJRNPtzuj ct5CqXMzgZLUsaKyz5q0m0AaKOLatGAST4Ylk=
In-reply-to: <20080925235453.GF27997@disturbed>
References: <48D9FDA1.8050701@xxxxxxxxx> <20080925002724.GA27997@disturbed> <48DB48E3.3020104@xxxxxxxxx> <20080925235453.GF27997@disturbed>
User-agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724)
On 2008-09-26 02:54, Dave Chinner wrote:
> On Thu, Sep 25, 2008 at 11:16:35AM +0300, Török Edwin wrote:
>   
>> On 2008-09-25 03:27, Dave Chinner wrote:
>>     
>>> On Wed, Sep 24, 2008 at 11:43:13AM +0300, Török Edwin wrote:
>>>       
>> Thanks for the suggestions, the time for rm has improved a bit, but is
>> still slower than reiserfs:
>>
>> time rm -rf gcc
>>
>> real    1m18.818s
>> user    0m0.156s
>> sys     0m11.777s
>>
>> Is there anything else I can try to make it faster?
>>     
>
> Buy more disks. ;)
>
> XFS is not really optimised for single disk, metadata intensive,
> small file workloads.

I have 6 disks, in raid10 :)

md4 : active raid10 sda3[0] sdf3[5] sdc3[4] sde3[3] sdd3[2] sdb3[1]
      2159617728 blocks 64K chunks 2 near-copies [6/6] [UUUUUU]

--- Logical volume ---
  LV Name                /dev/vg-all/lv-var
  VG Name                vg-all
  LV UUID                CQHPts-K3OE-9kWV-hg7q-328i-RP0i-Dew94c
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                1.27 TB
  Current LE             332800
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

  --- Segments ---
  Logical extent 0 to 332799:
    Type                linear
    Physical volume     /dev/md4
    Physical extents    25600 to 358399

>  It scales by being able to keep lots of disks
> busy at the same time. Those algorithms don't map to single disk
> configs as efficiently as a filesystem that was specifically
> designed for optimal performance for these workloads (like
> reiserfs). We're working on making it better, but that takes time....

I see.
Well the read performance is very good as I said in my initial email ;)

Thanks,
--Edwin

<Prev in Thread] Current Thread [Next in Thread>