On Thu, 12 Jan 2012, Edward Ned Harvey wrote:
Suppose you have a 1G file open, and a snapshot of this file is on disk from
a previous point in time.
for ( i=0 ; i<1trillion ; i++ ) {
seek(random integer in range[0 to 1G]);
write(4k);
}
Something like this would quickly try to write a bunch of separate and
scattered 4k blocks at different offsets within the file. Every 32 of these
4k writes would be write-coalesced into a single 128k on-disk block.
Sometime later, you read the whole file sequentially such as cp or tar or
cat. The first 4k come from this 128k block... The next 4k come from
another 128k block... The next 4k come from yet another 128k block...
Essentially, the file has become very fragmented and scattered about on the
physical disk. Every 4k read results in a random disk seek.
Are you talking about some other filesystem or are you talking about
zfs? Because zfs does not work like that ...
However, I did ignore the additional fragmentation due to using raidz
type formats. These break the 128K block into smaller chunks and so
there can be more fragmentation.
The worst case
fragmentation pecentage for 8K blocks (and 512-byte sectors) is 6.25%
((100*1/((8*1024)/512))).
You seem to be assuming that reading 512b disk sector and its neighboring
512b sector count as contiguous blocks. And since there are guaranteed to
be exactly 256 sectors in every 128k filesystem block, then there is no
fragmentation for 256 contiguous sectors, guaranteed. Unfortunately, the
512b sector size is just an arbitrary number (and variable, actually 4k on
modern disks), and the resultant percentage of fragmentation is equally
arbitrary.
Yes, I am saying that zfs writes its data in contiguous chunks
(filesystem blocksize in the case of mirrors).
To produce a number that actually matters - What you need to do is calculate
the percentage of time the disk is able to deliver payload, versus the
percentage of time the disk is performing time-wasting "overhead" operations
- seek and latency.
Yes, latency is the critical factor.
That's 944 times larger than the largest 128k block size currently in zfs,
and obviously larger still compared to what you mentioned - 4k or 8k
recordsizes or 512b disk sectors...
Yes, fragmentation is still important even with 128K chunks.
I would call that 100% fragmentation, because there are no contiguously
aligned sequential blocks on disk anywhere. But again, any measure of
"percent fragmentation" is purely arbitrary, unless you know (a) which type
I agree that the notion of percent fragmentation is arbitrary. I used
one that I invented, and which is based on underlying disk sectors
rather than filesystem blocks.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
