You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although the long term goal is to move to new bits, we might also want to play
around with the
current build and see if we can tweak out some more performance. I don't know
how much of the
performance difference these changes[1] come from just disabling checksums, but
it if is a long
time until we can get mac-zfs caught up… well, maybe we can at least make a
few people happy
with some better performance.
[1] http://lists.macosforge.org/pipermail/zfs-discuss/2009-September/001855.html
Original issue reported on code.google.com by jason.richard.mcneil on 2 Nov 2009 at 7:24
The text was updated successfully, but these errors were encountered:
Here's the nabble link, if/when the macosforge list gets removed:
http://n3.nabble.com/ZFS-performance-tuning-td21704.html#a21704
Note that the bug listed in here was part of 124, but here's the change:
hg log -r 0e96dd3b905a
Diff (against the hg) is attached. We may not be able to roll forward to this
until later.
Original comment by alex.ble...@gmail.com on 2 Nov 2009 at 11:37
I don't think it's going to be too long before we roll forwards, which will
bring some of those enhancements. In
any case, a lot of performance tuning is going to be load/machine/disk
dependent.
What will be really cool is to experiment with a separate ZIL device, which we
don't have yet (but I think was
added fairly soon after the 72 split).
By all means, let's discuss possibilities here, but as for code optimisations,
it might be difficult to roll forward
those in the future if we then pick up a good split point for ZFS.
Original comment by alex.ble...@gmail.com on 5 Nov 2009 at 9:49
Original issue reported on code.google.com by
jason.richard.mcneil
on 2 Nov 2009 at 7:24The text was updated successfully, but these errors were encountered: