lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 31 Oct 2012 10:30:21 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	"Darrick J. Wong" <darrick.wong@...cle.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: semi-stable page writes

On Mon, Oct 29, 2012 at 09:00:27PM -0400, Theodore Ts'o wrote:
> On Tue, Oct 30, 2012 at 09:01:22AM +1100, Dave Chinner wrote:
> > On Fri, Oct 26, 2012 at 03:19:09AM -0700, Darrick J. Wong wrote:
> > > Hi everyone,
> > > 
> > > Are people still annoyed about writes taking unexpectedly long amounts of tme
> > > due to the stable page write patchset?  I'm guessing yes...
> > 
> > I haven't heard anyone except th elunatic fringe complain
> > recently...
> 
> We are currently carrying a patch in the Google kernel which
> unconditionally disables stable page writes specifically because it
> introduced significant latencies that were unacceptable for some of
> our (internal) customers of said production kernel.
> 
> I'll leave it to others to decide whether the Google production kernel
> is part of the lunatic fringe or not.  :-)

Google is, and has the resources to maintain a lunatic fringe kernel
;)

Besides, we've discussed google's problem before, and it came down
to bad application design (i.e. no buffering to protect against
variable filesystem/storage latency) and not stable pages being the
source of the problem. Turning off stable pages was a hack to work
around a badly designed application stack....

....

> IMO, it would be better to have the system automatically do the right
> thing, though.  If there is no need for stable page writes, why pay
> the performance penalty for it?

Yes, and the right thing to do is to put correctness before
performance. Stable pages are needed for correctness in a lot of
cases, so that shoul dbe the default. If the user has performance
problems, then they can turn it off. At no time should the default
require tuning to get correct behaviour. case in point: filesystems
default to "barriers = on".

Safe should *always* be the default choice, even if it is sometimes
slow.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ