All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Lorenzo Allegrucci <l_allegrucci@despammed.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.6-mm5 oops mounting ext3 or reiserfs with -o barrier
Date: Sun, 23 May 2004 19:31:00 +0200	[thread overview]
Message-ID: <20040523173100.GA9914@suse.de> (raw)
In-Reply-To: <200405231917.52517.l_allegrucci@despammed.com>

On Sun, May 23 2004, Lorenzo Allegrucci wrote:
> On Sunday 23 May 2004 18:56, Jens Axboe wrote:
> 
> > > Untar, read, copy and remove the OpenOffice tarball, each test
> > > run with cold cache (mount/umount cycle).
> >
> > I understand that, I just don't see how you can call it a regression.
> > It's a given that barrier will be slower.
> 
> I'm sorry, I didn't know :)
> 
> I read from www.kerneltrap.org:
> 
> Request barriers, also known as write barriers, provide a mechanism for 

[snip]

Ah ok, I see the confusion! ext3 does nothing clever with barriers, it
just uses it for data integrity. A journalled fs is normally not safe to
run on write back cached drives if they aren't battery backed. You could
try reiser instead, it's has a more intelligent use of barriers.

> > > > but yes of course -o barrier=1 is going to
> > > > be slower than default + write back caching. What you should compare is
> > > > without barrier support and hdparm -W0 /dev/hdX, if -o barrier=1 with
> > > > caching on is slower then that's a regression :-)
> > >
> > > hdparm -W0 /dev/hda
> > >
> > > ext3 (-o barrier=0)
> > > untar		read		copy		remove
> > > 1m55.190s	0m27.633s	2m19.072s	0m21.348s
> > > 0m7.081s	0m1.189s	0m0.724s	0m0.083s
> > > 0m6.502s	0m3.244s	0m9.715s	0m1.633s
> > >
> > > ext3 (-o barrier=1)
> > > untar		read		copy		remove
> > > 1m55.358s	0m23.831s	2m16.674s	0m21.508s
> > > 0m7.153s	0m1.200s	0m0.748s	0m0.087s
> > > 0m6.775s	0m3.358s	0m9.985s	0m1.781s
> > >
> > >
> > > haparm -W1 /dev/hda
> > >
> > > ext3 (-o barrier=0)
> > > untar		read		copy		remove
> > > 0m55.405s	0m26.230s	1m28.765s	0m20.766s
> > > 0m7.195s	0m1.199s	0m0.773s	0m0.081s
> > > 0m6.502s	0m3.359s	0m9.672s	0m1.868s
> > >
> > > ext3 (-o barrier=1)
> > > untar		read		copy		remove
> > > 0m52.117s	0m28.502s	1m51.153s	0m25.561s
> > > 0m7.231s	0m1.209s	0m0.738s	0m0.071s
> > > 0m6.117s	0m3.191s	0m9.347s	0m1.635s
> >
> > Your results look a bit over the map, how many runs are your averaging
> > for each one?
> 
> Just one run, no averaging.
> Yes, it's not a scientific approach, but I have not enough time
> and this is my production machine :)
> By experience I can say that numbers between each run are quite
> stable and reproducible.

It just looks odd that eg reads vary as much as they do, and that -o
barrier=1 makes -W0 reads faster (and faster then -W1 even). remove
looks reasonable for -W1, but -W0 is still faster. That is _really_ odd.

-- 
Jens Axboe


  reply	other threads:[~2004-05-23 17:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-22 19:07 2.6.6-mm5 oops mounting ext3 or reiserfs with -o barrier Lorenzo Allegrucci
2004-05-22 19:21 ` Andrew Morton
2004-05-22 21:20   ` Jens Axboe
2004-05-22 21:30     ` Jens Axboe
2004-05-23  8:58       ` Lorenzo Allegrucci
2004-05-23  9:11         ` Jens Axboe
2004-05-23 10:03           ` Jens Axboe
2004-05-23 15:32             ` Lorenzo Allegrucci
2004-05-23 15:45               ` Jens Axboe
2004-05-23 16:43                 ` Lorenzo Allegrucci
2004-05-23 16:56                   ` Jens Axboe
2004-05-23 17:17                     ` Lorenzo Allegrucci
2004-05-23 17:31                       ` Jens Axboe [this message]
2004-05-23 20:41                         ` Lorenzo Allegrucci
2004-05-23  8:27 ` Jens Axboe
2004-05-23 10:37   ` Kurt Garloff
2004-05-23 10:56     ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040523173100.GA9914@suse.de \
    --to=axboe@suse.de \
    --cc=akpm@osdl.org \
    --cc=l_allegrucci@despammed.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.