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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 22 Apr 2008 21:21:49 -0400
From:	Theodore Tso <tytso@....edu>
To:	"Jose R. Santos" <jrs@...ibm.com>
Cc:	linux-ext4@...r.kernel.org,
	Valerie Clement <valerie.clement@...l.net>
Subject: Re: [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation
	for FLEX_BG

On Tue, Apr 22, 2008 at 05:27:51PM -0500, Jose R. Santos wrote:
> > Let's stay with 16 then for now.  Spindle speed doesn't actually
> > matter here; what matters is seek speed, and the density of the disk
> 
> Well higher spindle speed affect cylinder seek times which affect
> overall seek time, which is why I think it should be tested as well.

Well, I looked at some laptop drives with spindle speeds of 4200rpm,
5400rpm, and 7200rpm, and they have an average read/write seek time of
of 10.5/12.5ms.

Comparing Western Digital's current enterprise disk drives (the RE-2)
which are 7200rpm, and their Enterprise "Green Power" drives (the
RE2-GP) which try to hide the fact that their disks are 5400RPM, but
which web sites have outed by using doing a frequency analysis of its
acoustic output --- both have the same read/write seek time of 8.9ms.

Interestingly, some of the older disks have faster seek times (i.e.,
4ms), at the same disk platters, and I doubt it's because hard drive
head positioning motors have gotten slower; rather, it's probably that
as the platter density has increased, the time to position the hard
drive heads is what's taking longer.  

Something that would be interesting to do is to do some experiments
measuring small seeks (i.e., within a 1 gigabyte or so), and long
seeks (i.e., across 10-20% and 50% of the disk drive).  The difference
between those two times is what's probably driving your flex_bg
performance numbers, and it might be easier simply to measure that
directly.

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