linux-ext4 - Re: defrag deployment status (was Re: [PATCH] ext4: allow defrag (EXT4_IOC_MOVE

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, 10 Mar 2010 02:49:41 +1030
From:	David Newall <davidn@...idnewall.com>
To:	jim owens <owens6336@...il.com>
CC:	Christian Borntraeger <borntraeger@...ibm.com>,
	Jeff Garzik <jeff@...zik.org>, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org, Akira Fujita <a-fujita@...jp.nec.com>
Subject: Re: defrag deployment status (was Re: [PATCH] ext4: allow defrag
 (EXT4_IOC_MOVE_EXT) in 32bit compat mode)

jim owens wrote:
> No.  Your logic would be correct if rotating disks had
> similar speed at all locations.  Current disks are much
> faster at the 0 end than at the middle or highest address.
>   

I think  my logic is still correct, although I wished I had said "closer 
to the middle."  In fact, simplistic ideas for placement of files are 
unlikely to produce fabulous results (and that includes placing commonly 
used files towards the middle of the disk, say at the inside edge of the 
outermost zone.)  The effort that BSD went to in FFS, placing 
directories with files and meta-data in cylinder groups, illustrates 
that disk performance is a sophisticated problem.

Why don't we use BSD FFS/FFS2?
--
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