From: Dan Smith <danms@xxxxxxxxxx> Subject: Re: Latest dm-userspace kernel code Date: Sat, 30 Sep 2006 15:29:41 -0700 > >> In order for this to perform well, we will need to use AIO, right? > FT> I'm not sure about this. Can you elaborate? > > Well, assuming that a copy operation (and an fsync() to make sure it > is on-disk) is a non-trivial operation, it would be good to allow the > copy to happen in the background while still being able to service > other requests from the kernel. Seems that we ara not talking about the same thing. I'm talking about removing dmu_request->deps (dependent request feature). Seems that you are talking about DMU_FLAG_COPY_FIRST feature (it's ok for me). My point is that the dependent request feature can be done in user space easily. If a user-space program gets a request trying to perform I/Os in the same block that an outgoing request with DMU_FLAG_COPY_FIRST are performing I/Os too, it waits for the I/O completion and then submit the new request to kernel space. > In cowd, I need to write metadata when blocks are mapped, and fsync() > them to make sure they are on disk before I allow the IO to complete. > If I do this with a normal write()/fsync() (or open the file O_SYNC), > then cowd is blocked until the write is complete. This means that > other requests that are in the queue, which may not require a copy, > are also blocked unnecessarily. I assume that unless copy operations > are performed asynchronously (as they are now by letting the kernel do > it), the problem will get even worse. I think that AIO is essential for the metadata issue even with DMU_FLAG_COPY_FIRST and dependent request features, though the DMU_FLAG_COPY_FIRST feature is important for writing a newly allocated cow block. I thought your user-space programs uses AIO like blktap does, though the current AIO implementation lacks some important features. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
