From: Martin Steigerwald <Martin@lichtvoll.de>
To: xfs@oss.sgi.com
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: 12x performance drop on md/linux+sw raid1 due to barriers [xfs]
Date: Sun, 14 Dec 2008 19:33:36 +0100 [thread overview]
Message-ID: <200812141933.37398.Martin@lichtvoll.de> (raw)
Am Sonntag 14 Dezember 2008 schrieben Sie:
> Am Sonntag 14 Dezember 2008 schrieb Peter Grandi:
> > But talking about barriers in the context of metadata, and for a
> > "benchmark" which has a metadata barrier every 11KB, and without
> > knowing whether the storage subsystem can queue multiple barrier
> > operations seems to be pretty crass and meangingless, if not
> > misleading. A waste of time at best.
>
> Hmmm, as far as I understood it would be that the IO scheduler would
> handle barrier requests itself if the device was not capable for
> queuing and ordering requests.
>
> Only thing that occurs to me know, that with barriers off it has more
> freedom to order requests and that might matter for that metadata
> intensive workload. With barriers it can only order 11 KB of requests.
> Without it could order as much as it wants... but even then the
> filesystem would have to make sure that metadata changes land in the
> journal first and then in-place. And this would involve a sync, if no
> barrier request was possible.
No it hasn't. As I do not think XFS or any other filesystem would be keen
to see the IO scheduler reorder a journal write after a corresponding
meta data in-place write. So either the filesystem uses sync...
> So I still don't get why even that metadata intense workload of tar -xf
> linux-2.6.27.tar.bz2 - or may better bzip2 -d the tar before - should
> be slower with barriers + write cache on than with no barriers and
> write cache off.
... or it tells the scheduler that this journal write should come prior to
the later writes. This is what a barrier would do - except for that it
cannot utilize any additional in-hardware / in-firmware support.
So why on earth can write cache off + barrier off be faster than write
cache on + barrier on in *any workload*? There must be some technical
detail that I miss.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
WARNING: multiple messages have this Message-ID (diff)
From: Martin Steigerwald <Martin@lichtvoll.de>
To: xfs@oss.sgi.com
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: 12x performance drop on md/linux+sw raid1 due to barriers [xfs]
Date: Sun, 14 Dec 2008 19:33:36 +0100 [thread overview]
Message-ID: <200812141933.37398.Martin@lichtvoll.de> (raw)
Am Sonntag 14 Dezember 2008 schrieben Sie:
> Am Sonntag 14 Dezember 2008 schrieb Peter Grandi:
> > But talking about barriers in the context of metadata, and for a
> > "benchmark" which has a metadata barrier every 11KB, and without
> > knowing whether the storage subsystem can queue multiple barrier
> > operations seems to be pretty crass and meangingless, if not
> > misleading. A waste of time at best.
>
> Hmmm, as far as I understood it would be that the IO scheduler would
> handle barrier requests itself if the device was not capable for
> queuing and ordering requests.
>
> Only thing that occurs to me know, that with barriers off it has more
> freedom to order requests and that might matter for that metadata
> intensive workload. With barriers it can only order 11 KB of requests.
> Without it could order as much as it wants... but even then the
> filesystem would have to make sure that metadata changes land in the
> journal first and then in-place. And this would involve a sync, if no
> barrier request was possible.
No it hasn't. As I do not think XFS or any other filesystem would be keen
to see the IO scheduler reorder a journal write after a corresponding
meta data in-place write. So either the filesystem uses sync...
> So I still don't get why even that metadata intense workload of tar -xf
> linux-2.6.27.tar.bz2 - or may better bzip2 -d the tar before - should
> be slower with barriers + write cache on than with no barriers and
> write cache off.
... or it tells the scheduler that this journal write should come prior to
the later writes. This is what a barrier would do - except for that it
cannot utilize any additional in-hardware / in-firmware support.
So why on earth can write cache off + barrier off be faster than write
cache on + barrier on in *any workload*? There must be some technical
detail that I miss.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2008-12-14 18:33 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-14 18:33 Martin Steigerwald [this message]
2008-12-14 18:33 ` 12x performance drop on md/linux+sw raid1 due to barriers [xfs] Martin Steigerwald
-- strict thread matches above, loose matches on Subject: below --
2008-12-06 14:28 Justin Piszcz
2008-12-06 14:28 ` Justin Piszcz
2008-12-06 15:36 ` Eric Sandeen
2008-12-06 20:35 ` Redeeman
2008-12-06 20:35 ` Redeeman
2008-12-13 12:54 ` Justin Piszcz
2008-12-13 12:54 ` Justin Piszcz
2008-12-13 17:26 ` Martin Steigerwald
2008-12-13 17:26 ` Martin Steigerwald
2008-12-13 17:40 ` Eric Sandeen
2008-12-13 17:40 ` Eric Sandeen
2008-12-14 3:31 ` Redeeman
2008-12-14 3:31 ` Redeeman
2008-12-14 14:02 ` Peter Grandi
2008-12-14 14:02 ` Peter Grandi
2008-12-14 18:12 ` Martin Steigerwald
2008-12-14 18:12 ` Martin Steigerwald
2008-12-14 22:02 ` Peter Grandi
2008-12-14 22:02 ` Peter Grandi
2008-12-15 18:48 ` Martin Steigerwald
2008-12-15 22:50 ` Peter Grandi
2009-02-18 22:14 ` Leon Woestenberg
2009-02-18 22:24 ` Eric Sandeen
2009-02-18 23:09 ` Ralf Liebenow
2009-02-18 23:19 ` Eric Sandeen
2009-02-20 19:19 ` Peter Grandi
2008-12-15 22:38 ` Dave Chinner
2008-12-15 22:38 ` Dave Chinner
2008-12-16 9:39 ` Martin Steigerwald
2008-12-16 9:39 ` Martin Steigerwald
2008-12-16 20:57 ` Peter Grandi
2008-12-16 23:14 ` Dave Chinner
2008-12-16 23:14 ` Dave Chinner
2008-12-17 21:40 ` Bill Davidsen
2008-12-17 21:40 ` Bill Davidsen
2008-12-18 8:20 ` Leon Woestenberg
2008-12-18 23:33 ` Bill Davidsen
2008-12-21 19:16 ` Peter Grandi
2008-12-22 13:19 ` Leon Woestenberg
2008-12-22 13:19 ` Leon Woestenberg
2008-12-18 22:26 ` Dave Chinner
2008-12-18 22:26 ` Dave Chinner
2008-12-20 14:06 ` Peter Grandi
2008-12-14 18:35 ` Martin Steigerwald
2008-12-14 18:35 ` Martin Steigerwald
2008-12-14 17:49 ` Martin Steigerwald
2008-12-14 17:49 ` Martin Steigerwald
2008-12-14 23:36 ` Dave Chinner
2008-12-14 23:36 ` Dave Chinner
2008-12-14 23:55 ` Eric Sandeen
2008-12-13 18:01 ` David Lethe
2008-12-13 18:01 ` David Lethe
2008-12-06 18:42 ` Peter Grandi
2008-12-11 0:20 ` Bill Davidsen
2008-12-11 0:20 ` Bill Davidsen
2008-12-11 9:18 ` Justin Piszcz
2008-12-11 9:18 ` Justin Piszcz
2008-12-11 9:24 ` Justin Piszcz
2008-12-11 9:24 ` Justin Piszcz
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=200812141933.37398.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=linux-raid@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/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.