> You and I seem to have different interprettations of the > empirical "2x" soft-requirement to make dedup worthwhile. Well, until recently I had little interpretation for it at all, so your approach may be better. I hope that authors of the requirement statement would step forward and explain what it is about "under the hood" and why 2x ;) > You know what? A year ago I would have said dedup still > wasn't stable enough for production. Now I would say it's plenty stable > enough... But it needs performance enhancement before it's > truly useful for most cases.
Well, not that this would contradict you, but on my oi_148a (which may be based on code close to a year old), it seems rather unstable, with systems either freezing or slowing down after some writes and having to be rebooted in order to work (fresh after boot writes are usually relatively good, i.e. 5Mb/s vs. 100k/s). On the iSCSI server side, the LUN and STMF service often lock up with "device busy" even though the volume "pool/dcpool" is not itself deduped. For me this is only solved by a reboot... And reboots of the VM client which fights its way through deleting files from the deduped datasets inside "dcpool" (imported over iSCSI) are beyond counting. Actually in a couple of weeks I might be passing by that machine and may have a chance to update it to oi_151-dev, would that buy me any improvements, or potentially worsen my situation? ;) //Jim
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
