On Sep 14, 2010, at 4:58 AM, Edward Ned Harvey wrote:

>> From: Haudy Kazemi [mailto:kaze0...@umn.edu]
>> 
>> With regard to multiuser systems and how that negates the need to
>> defragment, I think that is only partially true.  As long as the files
>> are defragmented enough so that each particular read request only
>> requires one seek before it is time to service the next read request,
>> further defragmentation may offer only marginal benefit.  On the other
> 
> Here's a great way to quantify how much "fragmentation" is acceptable:
> 
> Suppose you want to ensure at least 99% efficiency of the drive.  At most 1%
> time wasted by seeking.

This is practically impossible on a HDD.  If you need this, use SSD.
This phenomenon is why "short-stroking" became popular, until SSDs
killed short-stroking.

> Suppose you're talking about 7200rpm sata drives, which sustain 500Mbit/s
> transfer, and have average seek time 8ms.
> 
> 8ms is 1% of 800ms.
> In 800ms, the drive could read 400 Mbit of sequential data.
> That's 40 MB

In UFS we have cluster groups -- doesn't survive the test of time. 
In ZFS we have metaslabs, perhaps with a better chance of longevity.
The vdev is divided into a set of metaslabs and the allocator tries to
use space in one metaslab before changing to another.

Several features work against HDD optimization. Redundant copies 
of the metadata are intentionally spread across the media, so that there
is some resilience to media errors. Entries into the ZIL can also be of
varying size and are allocated in the pool -- solved by using a separate 
log device. COW can lead to wikipedia disk [de]fragmentation for files
which are larger than the recordsize.

Continuing to try to optimize for  HDD performance is just a matter of 
changing the lipstick on the pig.
 -- richard

-- 
OpenStorage Summit, October 25-27, Palo Alto, CA
http://nexenta-summit2010.eventbrite.com

Richard Elling
rich...@nexenta.com   +1-760-896-4422
Enterprise class storage for everyone
www.nexenta.com





_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to