----- Original Message ----- From: "George Wilson" <george.wil...@delphix.com>
On 5/7/14, 11:46 AM, Steven Hartland wrote:----- Original Message ----- From: "George Wilson" <george.wil...@delphix.com>It's a safety issue. If you need to change the zio then you effectively need to execute a new pipeline for that zio. If you don't want to hand this off to a different taskq then call zio_execute() instead of zio_interrupt(). For the lower layers it makes sense to call zio_interrupt() since we typically call the completion routines from the interrupt taskqs anyways.There are a couple of cases where it can work but I'm going to make it such that requires you to always return back ZIO_PIPELINE_STOP. Otherwise it's makes it too easy to introduce a programming error. For example, vdev_mirror_io_start() could return ZIO_PIPELINE_CONTINUE but vdev_disk_io_start() shouldn't.I'll try to have a diff ready soon. I will be interested in your test results.I'm going to give this a go but requeuing the request in the task handler instead of processing it directly sounds like quite a waste. Whats the objection to continuing directly with the updated zio?
Hi George did you get chance to have a look that this yet? I've attached a patch, based on FreeBSD HEAD, which ensures that all paths from zio_vdev_io_start use: zio_interrupt(zio); return (ZIO_PIPELINE_STOP); instead of: return (ZIO_PIPELINE_CONTINUE); Along with asserting that the return from vdev_op_io_start is ZIO_PIPELINE_STOP. Is this what you had in mind? Regards Steve
zio-continue.patch
Description: Binary data
_______________________________________________ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer
