Daniel Carosone wrote:
On Mon, Jan 18, 2010 at 03:25:56PM -0800, Erik Trimble wrote:
Hopefully, once BP rewrite materializes (I know, I'm treating this
much to much as a Holy Grail, here to save us from all the ZFS
limitations, but really...), we can implement defragmentation which
will seriously reduce the amount of reserved space required to keep
up performance.
I doubt that. I expect bp-rewrite in general, and its use for
effective defragmentation in particular, to require rather *more* free
space to be available. Of course, you may be able to add that space by
stretching a raidz vdev to one more disk, but you also may not due to
other constraints (not enough ports, etc).
Really? I would expect that a frequent defragging (i.e. defrag as the
pool is used (say on a nightly basis), not just once it gets to 90%+
utilization) would seriously reduce the amount of reserved space
required, as it keeps the pool in a much more optimal layout, and thus
has a lower overhead requirement.
Other thought is that pools which are heavily used (and thus, likely to
need frequent defrag) would require more reserve than those which
contain relatively static datasets. It would certainly be helpful to
include a tunable parameter to ZFS so that it knows whether the dataset
is likely to be very write-intensive, or is generally
write-once-read-many. If the later case, I would expect that a couple
hundred MB is all that a pool would ever need for reserve space,
regardless of the actual pool size.
Another poster pointed out recently that you can readily add more
reserved space using an unmounted filesystem with a reservation of the
appropriate size. This is most relevant for systems without the "stop
looking a start ganging" fix.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
