On 5/7/14, 12:50 PM, Steven Hartland wrote:
----- 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>
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?
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.
Thanks for the explanation George, always good to get a better insight in
the the reasons behind things. This is the sort of thing that would be
great to capture in pipeline description comments for future readers.
Initial tests show the TRIM code still trips on the case where errors
return ZIO_PIPELINE_CONTINUE e.g.
zio->io_error = SET_ERROR(ENOTSUP);
return (ZIO_PIPELINE_CONTINUE);
I'm assuming in these cases we should be looking at the following
instead?
zio->io_error = SET_ERROR(ENOTSUP);
zio_interrupt(zio);
return (ZIO_PIPELINE_STOP);
And the same with:
switch (zio->io_type) {
case ZIO_TYPE_IOCTL:
/* XXPOLICY */
if (!vdev_readable(vd)) {
zio->io_error = SET_ERROR(ENXIO);
return (ZIO_PIPELINE_CONTINUE);
}
Regards
Steve
Steve,
That's correct. I will add some more documentation about this with my
proposed change.
Thanks,
George
_______________________________________________
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
