On Sat, 7 Jan 2012, Jim Klimov wrote:
I understand that relatively high fragmentation is inherent
to ZFS due to its COW and possible intermixing of metadata
and data blocks (of which metadata path blocks are likely
to expire and get freed relatively quickly).
To put things in proper perspective, with 128K filesystem blocks, the
worst case file fragmentation as a percentage is 0.39%
(100*1/((128*1024)/512)). On a Microsoft Windows system, the
defragger might suggest that defragmentation is not warranted for this
Finally, what would the gurus say - does fragmentation
pose a heavy problem on nearly-filled-up pools made of
spinning HDDs (I believe so, at least judging from those
performance degradation problems writing to 80+%-filled
pools), and can fragmentation be effectively combatted
on ZFS at all (with or without BP rewrite)?
There are different types of fragmentation. The fragmentation which
causes a slowdown when writing to an almost full pool is fragmentation
of the free-list/area (causing zfs to take longer to find free space
to write to) as opposed to fragmentation of the files themselves.
The files themselves will still not be fragmented any more severely
than the zfs blocksize. However, there are seeks and there are
*seeks* and some seeks take longer than others so some forms of
fragmentation are worse than others. When the free space is
fragmented into smaller blocks, there is necessarily more file
fragmentation then the file is written.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
zfs-discuss mailing list