xfs
[Top] [All Lists]

Re: Little questions

To: Stephen Lord <lord@xxxxxxx>
Subject: Re: Little questions
From: Chris Wedgwood <cw@xxxxxxxx>
Date: Wed, 6 Nov 2002 11:31:37 -0800
Cc: yoros@xxxxxxxxxx, linux-xfs <linux-xfs@xxxxxxxxxxx>
In-reply-to: <1035932635.1088.43.camel@xxxxxxxxxxxxxxxxxxxxxxx>
References: <20021027214706.GA5589@xxxxxxxxxxxxxxxxxxx> <1035817834.18751.24.camel@xxxxxxxxxxxxxxxxxxxx> <20021028225113.GA12476@xxxxxxxxxxxxxxxxxxx> <20021029195735.GC5708@xxxxxxxxxxxxx> <20021029223018.GB18631@xxxxxxxxxxxxxxxxxxx> <1035932635.1088.43.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4i
On Tue, Oct 29, 2002 at 05:03:53PM -0600, Stephen Lord wrote:

> for every block in the file ext2 needs to free this block and place
> it in the bitmaps. For xfs the same is true, it needs to free each
> extent.  One of the issues with a journalled filesystem is we need
> to keep the filesystem consistent between each transaction. The
> amount of work in removing a file is unbounded, and a transaction
> needs to have a bounded size (don't ask it gets really
> complicated). But what it means is that removing a file takes
> multiple transactions, and those end up causing disk I/O.

Perhaps it's fairer to compare with ext3 then?

Bert Hubert <ahu@xxxxxxx> just posted this to l-k:

> Subject: naive but spectacular ext3 HTREE+Orlov benchmark

[...]

> Summary of HTREE ext3 Orlov vs non-Orlov, in real minute:seconds

>                                 2.5.45  2.5.46
> ----------------------------------------------
> unpacking kernel tar.bz2:       1:26    1:16
> cold traversal:                 1:01.5  0:42.9
> hot traversal:                  0:51.0  0:34.5
> delete                          0:05.3  <0:02



Now, this gives an upper bound for 5.3s to delete a kernel tree when
'hot' in cache.  I can't really compare the extraction times as my CPU
is faster but the tarball bzip2'd.

For me (testing with 2.5.39 tarball as it's the most recent complete
tarball I have):


charon:~/test% /usr/bin/time find . -noleaf -type f > /dev/null
0.03user 0.16system 0:00.18elapsed 101%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (100major+22minor)pagefaults 0swaps


charon:~/test% /usr/bin/time du -s
178824  .
0.01user 0.16system 0:00.17elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (106major+22minor)pagefaults 0swaps


charon:~/test% sync ; /usr/bin/time rm -r linux-2.5.39
0.03user 1.48system 0:23.57elapsed 6%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (95major+14minor)pagefaults 0swaps



So given pretty good conditions (ie. faster desktop compared to slower
laptop) XFS is many times slower at deleting multiple files and
ext3. With the orlov patch on ext3 (which gives a degree of location
affinity to files in a directory tree) ext3 is *over* ten times
faster at removing multiple files than XFS.


I'm assuming this is mostly because XFS is vastly more complex in it's
logging (it makes my head hurt and the more I look at it I wonder if
all the complexity is necessary), but perhaps something else may
explain the massive disparity?


I did test with 2.4.x and can with 2.5.x later if it matters, but I
don't see that buying me 10x speedup or anything close.



  --cw


<Prev in Thread] Current Thread [Next in Thread>
  • Re: Little questions, Chris Wedgwood <=