public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Peter Grandi <pg@lxra2.to.sabi.co.UK>
Cc: Linux RAID <linux-raid@vger.kernel.org>, Linux fs XFS <xfs@oss.sgi.com>
Subject: Re: raid10n2/xfs setup guidance on write-cache/barrier
Date: Sun, 18 Mar 2012 13:08:35 -0500	[thread overview]
Message-ID: <4F6624A3.5010206@hardwarefreak.com> (raw)
In-Reply-To: <20325.50714.237894.328039@tree.ty.sabi.co.UK>

On 3/18/2012 6:25 AM, Peter Grandi wrote:

> So in my view 'delaylog' cannot be described boldly and barely
> described, especially in this thread, as an improvement in XFS
> performance, as it is an improvement in XFS's unsafety to obtain
> greater speed, similar to but not as extensive as 'nobarrier'.

You have recommended in various past posts on multiple lists that users
should max out logbsize and logbufs to increase metadata performance.
You made no mention in those posts about safety as you have here.
Logbufs are in-memory journal write buffers and are volatile.  Delaylog
uses in-memory structures that are volatile.  So, why do you consider
logbufs to be inherently safer than delaylog?  Following the logic
you've used in this thread, both should be considered equally unsafe.
Yet I don't recall you ever preaching against logbufs in the past.  Is
it because logbufs can 'only' potentially lose 2MB worth of metadata
transactions, and delaylog can potentially lose more than 2MB?

> In the same way that 'eatmydata':

Hardly.  From: http://packages.debian.org/sid/eatmydata

"This package ... transparently disable fsync ... two side-effects: ...
writes data ... quicker ... no longer crash safe ... useful if
particular software calls fsync(), sync() etc. frequently but *the data
it stores is not that valuable to you* and you may *afford losing it in
case of system crash*."

So you're comparing delaylog's volatile buffer architecture to software
that *intentionally and transparently disables fsync*?  So do you
believe a similar warning should be attached to the docs for delaylog?
And thus to the use of logbufs as well?  How about all write
buffers/caches in the Linux kernel?

Where exactly do you draw the line Peter, between unsafe/safe use of
in-memory write buffers?  Is there some magical demarcation point
between synchronous serial IO, and having gigabytes of inflight write
data in memory buffers?

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2012-03-18 18:08 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAA8mOyDKrWg0QUEHxcD4ocXXD42nJu0TG+sXjC4j2RsigHTcmw@mail.gmail.com>
     [not found] ` <4F61803A.60009@hardwarefreak.com>
     [not found]   ` <CAA8mOyCzs36YD_QUMq25HQf8zuq1=tmSTPjYdoFJwy2Oq9sLmw@mail.gmail.com>
2012-03-15 14:07     ` raid10n2/xfs setup guidance on write-cache/barrier Peter Grandi
2012-03-15 15:25       ` keld
2012-03-15 16:52         ` Jessie Evangelista
2012-03-15 17:15           ` keld
2012-03-15 17:40             ` keld
2012-03-15 16:18       ` Jessie Evangelista
2012-03-15 23:00         ` Peter Grandi
2012-03-16  3:36           ` Jessie Evangelista
2012-03-16 11:06             ` Michael Monnerie
2012-03-16 12:21               ` Peter Grandi
2012-03-16 17:15             ` Brian Candler
2012-03-17 15:35             ` Peter Grandi
2012-03-17 21:39               ` raid10n2/xfs setup guidance on write-cache/barrier (GiB alignment) Zdenek Kaspar
2012-03-18  0:08                 ` Peter Grandi
2012-03-26 19:50               ` raid10n2/xfs setup guidance on write-cache/barrier Martin Steigerwald
2012-03-17  4:21       ` NOW:Peter goading Dave over delaylog - WAS: " Stan Hoeppner
2012-03-17 22:34         ` Dave Chinner
2012-03-18  2:09           ` Peter Grandi
2012-03-18 11:25             ` Peter Grandi
2012-03-18 14:00               ` Christoph Hellwig
2012-03-18 19:17                 ` Peter Grandi
2012-03-19  9:07                   ` Stan Hoeppner
2012-03-20 12:34                     ` Jessie Evangelista
2012-03-18 18:08               ` Stan Hoeppner [this message]
2012-03-22 21:26                 ` Peter Grandi
2012-03-23  5:10                   ` Stan Hoeppner
2012-03-23 22:48                   ` Martin Steigerwald
2012-03-24  1:27                     ` Peter Grandi
2012-03-24 16:27                       ` GNU 'tar', Schilling's 'tar', write-cache/barrier Peter Grandi
2012-03-24 17:11                         ` Brian Candler
2012-03-24 18:35                           ` Peter Grandi
     [not found]     ` <4F633121.10800@hardwarefreak.com>
     [not found]       ` <CAKuK5J3GHgWcnYLqwRV8s_wMjO2nBVf7h=yONtn90kPn9A_3Gg@mail.gmail.com>
     [not found]         ` <CAKuK5J11JTdwZSBWj7DH7c+hE--MVNQVVrcKXaV2AO-wEpWBog@mail.gmail.com>
2012-03-16 19:28           ` raid10n2/xfs setup guidance on write-cache/barrier Peter Grandi
2012-03-17  0:02             ` Stan Hoeppner

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=4F6624A3.5010206@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=pg@lxra2.to.sabi.co.UK \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox