[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] Latest dm-userspace kernel code



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 us ibm com

Attachment: pgpe6pmOrKaYN.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]