From: Jamie Lokier <jamie@shareable.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>,
gus3 <musicman529@yahoo.com>,
Szabolcs Szakacsits <szaka@ntfs-3g.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
xfs@oss.sgi.com
Subject: Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system)
Date: Mon, 25 Aug 2008 13:01:47 +0100 [thread overview]
Message-ID: <20080825120146.GC20960@shareable.org> (raw)
In-Reply-To: <20080825015922.GP5706@disturbed>
Dave Chinner wrote:
> To keep on top of this, we keep adding new variations and types and
> expect the filesystems to make best use of them (without
> documentation) to optimise for certain situations. Example - the
> new(ish) BIO_META tag that only CFQ understands. I can change the
> way XFS issues bios to use this tag to make CFQ behave the same way
> it used to w.r.t. metadata I/O from XFS, but then the deadline and
> AS will probably regress because they don't understand that tag and
> still need the old optimisations that just got removed. Ditto for
> prioritised bio dispatch - CFQ supports it but none of the others
> do.
There's nothing wrong with adding BIO_META (for example) and other
hints in _principle_. You should be able to ignore it with no adverse
effects. If its not used by a filesystem (and there's nothing else
competing to use the same disk), I would hope to see the same
performance as other kernels which don't have it.
If the elevators are being changed in such a way that old filesystem
code which doesn't use new hint bits is running significantly slower,
surely that's blatant elevator regression, and that's where the bugs
should be reported and fixed?
-- Jamie
WARNING: multiple messages have this Message-ID (diff)
From: Jamie Lokier <jamie@shareable.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>,
gus3 <musicman529@yahoo.com>,
Szabolcs Szakacsits <szaka@ntfs-3g.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system)
Date: Mon, 25 Aug 2008 13:01:47 +0100 [thread overview]
Message-ID: <20080825120146.GC20960@shareable.org> (raw)
In-Reply-To: <20080825015922.GP5706@disturbed>
Dave Chinner wrote:
> To keep on top of this, we keep adding new variations and types and
> expect the filesystems to make best use of them (without
> documentation) to optimise for certain situations. Example - the
> new(ish) BIO_META tag that only CFQ understands. I can change the
> way XFS issues bios to use this tag to make CFQ behave the same way
> it used to w.r.t. metadata I/O from XFS, but then the deadline and
> AS will probably regress because they don't understand that tag and
> still need the old optimisations that just got removed. Ditto for
> prioritised bio dispatch - CFQ supports it but none of the others
> do.
There's nothing wrong with adding BIO_META (for example) and other
hints in _principle_. You should be able to ignore it with no adverse
effects. If its not used by a filesystem (and there's nothing else
competing to use the same disk), I would hope to see the same
performance as other kernels which don't have it.
If the elevators are being changed in such a way that old filesystem
code which doesn't use new hint bits is running significantly slower,
surely that's blatant elevator regression, and that's where the bugs
should be reported and fixed?
-- Jamie
next prev parent reply other threads:[~2008-08-25 12:00 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-20 2:45 [PATCH RFC] nilfs2: continuous snapshotting file system Ryusuke Konishi
2008-08-20 7:43 ` Andrew Morton
2008-08-20 8:22 ` Pekka Enberg
2008-08-20 18:47 ` Ryusuke Konishi
2008-08-20 16:13 ` Ryusuke Konishi
2008-08-20 21:25 ` Szabolcs Szakacsits
2008-08-20 21:39 ` Andrew Morton
2008-08-20 21:48 ` Szabolcs Szakacsits
2008-08-21 2:12 ` Dave Chinner
2008-08-21 2:46 ` Szabolcs Szakacsits
2008-08-21 5:15 ` XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) Dave Chinner
2008-08-21 6:00 ` gus3
2008-08-21 6:14 ` Dave Chinner
2008-08-21 7:00 ` Nick Piggin
2008-08-21 8:53 ` Dave Chinner
2008-08-21 9:33 ` Nick Piggin
2008-08-21 17:08 ` Dave Chinner
2008-08-21 17:08 ` Dave Chinner
2008-08-22 2:29 ` Nick Piggin
2008-08-22 2:29 ` Nick Piggin
2008-08-25 1:59 ` Dave Chinner
2008-08-25 4:32 ` Nick Piggin
2008-08-25 12:01 ` Jamie Lokier [this message]
2008-08-25 12:01 ` Jamie Lokier
2008-08-26 3:07 ` Dave Chinner
2008-08-26 3:50 ` david
2008-08-27 1:20 ` Dave Chinner
2008-08-27 21:54 ` david
2008-08-28 1:08 ` Dave Chinner
2008-08-21 14:52 ` Chris Mason
2008-08-21 14:52 ` Chris Mason
2008-08-21 6:04 ` Dave Chinner
2008-08-21 8:07 ` Aaron Carroll
2008-08-21 8:25 ` Dave Chinner
2008-08-21 11:02 ` Martin Steigerwald
2008-08-21 15:00 ` Martin Steigerwald
2008-08-21 15:00 ` Martin Steigerwald
2008-08-21 17:10 ` Szabolcs Szakacsits
2008-08-21 17:33 ` Szabolcs Szakacsits
2008-08-22 2:24 ` Dave Chinner
2008-08-22 6:49 ` Martin Steigerwald
2008-08-22 6:49 ` Martin Steigerwald
2008-08-22 12:44 ` Szabolcs Szakacsits
2008-08-23 12:52 ` Szabolcs Szakacsits
2008-08-21 11:53 ` Matthew Wilcox
2008-08-21 15:56 ` Dave Chinner
2008-08-21 12:51 ` [PATCH RFC] nilfs2: continuous snapshotting file system Chris Mason
2008-08-26 10:16 ` Jörn Engel
2008-08-26 16:54 ` Ryusuke Konishi
2008-08-27 18:13 ` Jörn Engel
2008-08-27 18:13 ` Jörn Engel
2008-08-27 18:19 ` Jörn Engel
2008-08-27 18:19 ` Jörn Engel
2008-08-29 6:29 ` Ryusuke Konishi
2008-08-29 8:40 ` Arnd Bergmann
2008-08-29 10:51 ` konishi.ryusuke
2008-08-29 11:04 ` Jörn Engel
2008-08-29 10:45 ` Jörn Engel
2008-08-29 10:45 ` Jörn Engel
2008-08-29 16:37 ` Ryusuke Konishi
2008-08-29 16:37 ` Ryusuke Konishi
2008-08-29 19:16 ` Jörn Engel
2008-08-29 19:16 ` Jörn Engel
2008-09-01 12:25 ` Ryusuke Konishi
2008-09-01 12:25 ` Ryusuke Konishi
2008-08-20 9:47 ` Andi Kleen
2008-08-21 4:57 ` Ryusuke Konishi
-- strict thread matches above, loose matches on Subject: below --
2008-08-21 11:05 XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) Martin Knoblauch
2008-08-21 11:05 ` Martin Knoblauch
2008-08-21 15:59 ` Dave Chinner
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=20080825120146.GC20960@shareable.org \
--to=jamie@shareable.org \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=musicman529@yahoo.com \
--cc=nickpiggin@yahoo.com.au \
--cc=szaka@ntfs-3g.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.