linux-ext4 - Re: [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation for FLEX

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]

Message-ID: <20080423012149.GF20668@mit.edu>
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