linux-kernel - Re: Linux 2.6.29

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:	Mon, 30 Mar 2009 09:13:20 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ric Wheeler <rwheeler@...hat.com>
cc:	Mark Lord <lkml@....ca>, Chris Mason <chris.mason@...cle.com>,
	"Andreas T.Auer" <andreas.t.auer_lkml_73537@...us.ath.cx>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Theodore Tso <tytso@....edu>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Jeff Garzik <jeff@...zik.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Rees <drees76@...il.com>, Jesper Krogh <jesper@...gh.cc>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.29

On Mon, 30 Mar 2009, Ric Wheeler wrote:
> 
> A modern S-ATA drive has up to 32MB of write cache. If you lose power or
> suffer a sudden reboot (that can reset the bus at least), I am pretty sure
> that your above assumption is simply not true.

At least traditionally, it's worth to note that 32MB of on-disk cache is 
not the same as 32MB of kernel write cache.

The drive caches tend to be more like track caches - you tend to have a 
few large cache entries (segments), not something like a sector cache. And 
I seriously doubt the disk will let you fill them up with writes: it 
likely has things like the sector remapping tables in those caches too.

It's hard to find information about the cache organization of modern 
drives, but at least a few years ago, some of them literally had just a 
single segment, or just a few segments (ie a "8MB cache" might be eight 
segments of one megabyte each).

The reason that matters is that those disks are very good at linear 
throughput.

The latency for writing out eight big segments is likely not really 
noticeably different from the latency of writing out eight single sectors 
spread out across the disk - they both do eight operations, and the 
difference between an op that writes a big chunk of a track and writing a 
single sector isn't necessarily all that noticeable.

So if you have a 8MB drive cache, it's very likely that the drive can 
flush its cache in just a few seeks, and we're still talking milliseconds. 
In contrast, even just 8MB of OS caches could have _hundreds_ of seeks and 
take several seconds to write out.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/