public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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