On Fri, Dec 18, 2015 at 10:41 AM, Matthew Ahrens <[email protected]> wrote:
> I have 2 outstanding review requests that I could use feedback on. These > have been open for quite a while so I'm probably going to RTI them this > weekend. > > Provide mechanism to artificially limit disk performance > https://github.com/openzfs/openzfs/pull/39 > FWIW, I also wrote up a short article about this change. E.g. how to use it, and an example of how to verify it's working using dtrace. Not sure if that'll make it any more approachable to review.... http://www.prakashsurya.com/2015/12/07/openzfs-artificial-disk-latency-using-zinject/ > This patch hijacks the existing 'zinject -D MSECS -d GUID' command, > slightly modifying it's interface and behavior to allow a user to > set per disk target latencies for IO requests. This is useful when > trying to run performance tests, and/or make performance critical > changes, but need to rule out the normal variance of hard drives. Using > this facility, the user can configure a disk to complete each IO request > in a configurable amount of time while also configuring the number of > 'lanes' of the device (i.e. the number concurrent IO requests possible). > For example, the following will configure the disk to complete each IO > > 6370 ZFS send fails to transmit some holes > https://github.com/openzfs/openzfs/pull/37 > > In certain circumstances, "zfs send -i" (incremental send) can produce a > stream which will result in incorrect sparse file contents on the > target. > *illumos-zfs* | Archives > <https://www.listbox.com/member/archive/182191/=now> > <https://www.listbox.com/member/archive/rss/182191/27764512-557e5721> | > Modify > <https://www.listbox.com/member/?member_id=27764512&id_secret=27764512-b472150b> > Your Subscription <http://www.listbox.com> >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
