FT> - I think that you can use kernel threads for map_worker since FT> dmu_map says that we might reorder I/Os. Yes, I think you are probably right. I disabled the kernel thread at one point as a sanity check, but I think it might be ok to turn it back on. I'll do some testing. FT> - What is the purpose of dmu_request->deps? I guess that it is for FT> preventing I/O being reordered. if so, again, you don't need to do FT> that. Well, the problem is that a block copy would overwrite other requests. I think that while a copy is happening, you have to be careful to not write into that block so that your writes are not lost. Am I over-thinking it? FT> - Would be better to move non-transport functions (map_worker, FT> copy_block, etc) to dm-userspace.c? Yes. You did a much better job of isolating those functions than I did :) ... I plan to revisit that soon. FT> - How does the current kernel/user interface support multiple FT> destination feature? I'm not sure what you mean here. Can you elaborate? FT> - Needs some cosmetic fixes (removing needless whitespaces and FT> braces, etc) Indeed. I made sure to mention in my post that it was not in "final form" for this reason :) I'll try to clean it up a little more before I post it again. Thanks for the feedback! -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@xxxxxxxxxx
Attachment:
pgpy6KR4F5wHw.pgp
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
