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?