From: Neil Brown <neilb@suse.de>
To: xfs@oss.sgi.com
Subject: XFS and write barriers.
Date: Fri, 23 Mar 2007 12:26:31 +1100 [thread overview]
Message-ID: <17923.11463.459927.628762@notabene.brown> (raw)
Hi,
I have two concerns related to XFS and write barrier support that I'm
hoping can be resolved.
Firstly in xfs_mountfs_check_barriers in fs/xfs/linux-2.6/xfs_super.c,
it tests ....->queue->ordered to see if that is QUEUE_ORDERED_NONE.
If it is, then barriers are disabled.
I think this is a layering violation - xfs really has no business
looking that deeply into the device.
For dm and md devices, ->ordered is never used and so never set, so
xfs will never use barriers on those devices (as the default value is
0 or NONE). It is true that md and dm could set ->ordered to some
non-zero value just to please XFS, but that would be telling a lie and
there is no possible value that is relevant to a layered devices.
I think this test should just be removed and the xfs_barrier_test
should be the main mechanism for seeing if barriers work.
Secondly, if a barrier write fails due to EOPNOTSUPP, it should be
retried without the barrier (after possibly waiting for dependant
requests to complete). This is what other filesystems do, but I
cannot find the code in xfs which does this.
The approach taken by xfs_barrier_test seems to suggest that xfs does
do this... could someone please point me to the code ?
This is particularly important for md/raid1 as it is quite possible
that barriers will be supported at first, but after a failure and
different device on a different controller could be swapped in that
does not support barriers.
Thanks for your time,
NeilBrown
next reply other threads:[~2007-03-23 1:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-23 1:26 Neil Brown [this message]
2007-03-23 5:30 ` XFS and write barriers David Chinner
2007-03-23 7:49 ` Neil Brown
2007-03-25 4:17 ` David Chinner
2007-03-25 23:21 ` Neil Brown
2007-03-26 3:14 ` David Chinner
2007-03-26 4:27 ` Neil Brown
2007-03-26 9:04 ` David Chinner
2007-03-29 14:56 ` Martin Steigerwald
2007-03-29 15:18 ` David Chinner
2007-03-29 16:49 ` Martin Steigerwald
2007-03-23 9:50 ` Christoph Hellwig
2007-03-25 3:51 ` David Chinner
2007-03-25 23:58 ` Neil Brown
2007-03-26 1:11 ` Neil Brown
2007-03-23 6:20 ` Timothy Shimmin
2007-03-23 8:00 ` Neil Brown
2007-03-25 3:19 ` David Chinner
2007-03-26 0:01 ` Neil Brown
2007-03-26 3:58 ` David Chinner
2007-03-27 3:58 ` Timothy Shimmin
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=17923.11463.459927.628762@notabene.brown \
--to=neilb@suse.de \
--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.