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:	Sat, 4 Apr 2009 20:01:08 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Theodore Tso <tytso@....edu>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [GIT PULL] Ext3 latency fixes

On Sat, Apr 04 2009, Linus Torvalds wrote:
> 
> 
> On Sat, 4 Apr 2009, Jens Axboe wrote:
> > > 
> > > I'm sorry, but that fsync thing _is_ a real-world case, and it's the one 
> > > that a hell of a lot more people care about than some idiotic sqlite 
> > > throughput issue.
> > 
> > sqlite is just one case, I'm sure there are others. My point is that we
> > should make sure that we don't regress on the throughput side. It's a
> > trade off, we don't want throughput to fall through the floor either.
> 
> Jens, we _have_ regressed on the latency side. Everybody agrees. 

It appears so, yes.

> Also, I may be odd, but I really do think latency is more important than 
> throughput. When my disk has latencies in the sub-milliseconds, I simply 
> do not think it is _acceptable_ to have hickups that affect my workload in 
> human-visible terms. 

Not everyone has an Intel SSD. But yes, latency is definitely more
important than throughput. That's not the same as saying that throughput
doesn't matter, because it definitely does.

> You say sqlite might regress by 4-5x. But Ted's numbers improve latencies 
> by mor than that. I haven't re-created them yet myself (still reading 
> email), but the point is, 4-5x may sound bad to you, but turn it around: 
> the current latency situation is _really_ bad. If we can fix it, we 
> definitely should.

I haven't either. On monday I'll throw some testing and patches on the
boxes here. We can get the latency right, I want that as much as the
next guy. I just want to make sure it doesn't become too one-sided.

> > > Quite frankly, the fact that I can see _seconds_ of latencies with a 
> > > really good SSD is not acceptable. The fact that it is by design is even 
> > > less so.
> > 
> > Agree, multi-second latencies is not acceptable.
> 
> I can literally send you strace output from my MUA, where it pauses for 
> ten seconds after it has written about 5kB (that's _kilobytes_) of data 
> and does a 'fsync'.

Unless you make all journal writes sync, ext3 fsync will always suck big
time. But I get your point.

-- 
Jens Axboe

--
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