From: Eric Sandeen <sandeen@sandeen.net>
To: Leon Woestenberg <leonw@mailcan.com>
Cc: Linux XFS <linux-xfs@oss.sgi.com>,
Peter Grandi <pg_xf2@xf2.for.sabi.co.UK>
Subject: Re: 12x performance drop on md/linux+sw raid1 due to barriers [xfs]
Date: Wed, 18 Feb 2009 16:24:31 -0600 [thread overview]
Message-ID: <499C8A9F.3030303@sandeen.net> (raw)
In-Reply-To: <B50173E3-7975-4A71-903A-A76D910CBB3A@mailcan.com>
Leon Woestenberg wrote:
> Hello,
>
> On 15 dec 2008, at 23:50, Peter Grandi wrote:
>
>> [ ... ]
>>
>>>> The purpose of barriers is to guarantee that relevant data is
>>>> known to be on persistent storage (kind of hardware 'fsync').
>>>>
>>> [ ... ] Unfortunately in my understanding none of this is
>>> reflected by Documentation/block/barrier.txt
>> But we are talking about XFS and barriers here. That described
>> just a (flawed, buggy) mechanism to implement those. Consider
>> for example:
>>
>> http://www.xfs.org/index.php/XFS_FAQ#Write_barrier_support.
>> http://www.xfs.org/index.php/XFS_FAQ#Q._Should_barriers_be_enabled_with_storage_which_has_a_persistent_write_cache.3F
>>
>> In any case as to the kernel "barrier" mechanism, its
>> description is misleading because it heavily fixates on the
>> ordering issue, which is just a consequence, but yet mentions
>> the far more important "flush/sync" aspect.
>>
>> Still, there is a lot of confusion about barrier support and
>> what it means at which level, as reflected in several online
>> discussions and the different behaviour of different kernel
>> versions.
>>
> The semantics of a barrier are whatever semantics we describe to it.
> So we can continue to be confused about it.
>
> I strongly disagree on the ordering issue being a side effect.
>
> Correct ordering can be proven to be enough to provide transactional
> correctness, enough to ensure that filesystems can not get corrupted
> on power down.
>
> Using barriers to guarantee that (all submitted) write requests
> (before the barrier) made it to the medium are a stronger predicate.
>
> The Linux approach and documentation talks about the first type of
> semantics (which I rather like for them being strong enough and not
> more).
Agreed. I'll have a look over those (wiki) faq entries and make sure
they're not confusing cache flushes with ordering requirements.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-02-18 22:25 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-06 14:28 12x performance drop on md/linux+sw raid1 due to barriers [xfs] Justin Piszcz
2008-12-06 15:36 ` Eric Sandeen
2008-12-06 20:35 ` Redeeman
2008-12-13 12:54 ` Justin Piszcz
2008-12-13 17:26 ` Martin Steigerwald
2008-12-13 17:40 ` Eric Sandeen
2008-12-14 3:31 ` Redeeman
2008-12-14 14:02 ` Peter Grandi
2008-12-14 18:12 ` Martin Steigerwald
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 [this message]
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-16 9:39 ` Martin Steigerwald
2008-12-16 20:57 ` Peter Grandi
2008-12-16 23:14 ` Dave Chinner
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-18 22:26 ` Dave Chinner
2008-12-14 18:35 ` Martin Steigerwald
2008-12-14 17:49 ` Martin Steigerwald
2008-12-14 23:36 ` Dave Chinner
2008-12-14 23:55 ` Eric Sandeen
2008-12-13 18:01 ` David Lethe
2008-12-06 18:42 ` Peter Grandi
2008-12-11 0:20 ` Bill Davidsen
2008-12-11 9:18 ` Justin Piszcz
2008-12-11 9:24 ` Justin Piszcz
-- strict thread matches above, loose matches on Subject: below --
2008-12-14 18:33 Martin Steigerwald
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=499C8A9F.3030303@sandeen.net \
--to=sandeen@sandeen.net \
--cc=leonw@mailcan.com \
--cc=linux-xfs@oss.sgi.com \
--cc=pg_xf2@xf2.for.sabi.co.UK \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox