Anthony Liguori wrote:
Mounting a partition being served on the same host as read-write can
cause deadlocks. From nbd-2.9.0 README file:
This text is pretty old. Is this still valid? This would imply that
things like loop can result in dead locks. I don't see why flushing
one device would depend on the completion of another device.
Otherwise, if you had two disk adapters, they would always be
operating in lock step.
As I've said, I've never seen a problem doing-write with nbd on
localhost.
A deadlock can happen under heavy I/O load:
- write tons of data to nbd device, data ends up in pagecache
- memory gets low, kswapd wakes up, calls nbd device to actually write
the data
- nbd issues a request, which ends up on the nbd server on the same machine
- the nbd server allocates memory
- memory allocation hangs waiting for kswapd
I submitted a patch/workaround for this some years ago (for a similar
problem with a local mount to a userspace nfs server).
--
error compiling committee.c: too many arguments to function
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
