From: "Richard W.M. Jones" <rjones@redhat.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: kernel list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>, Wouter Verhelst <w@uter.be>,
nbd@other.debian.org
Subject: Re: nbd, nbdkit, loopback mounts and memory management
Date: Fri, 15 Feb 2019 22:41:26 +0000 [thread overview]
Message-ID: <20190215224126.GX12500@redhat.com> (raw)
In-Reply-To: <20190215191953.GB17897@amd>
On Fri, Feb 15, 2019 at 08:19:54PM +0100, Pavel Machek wrote:
> Hi!
>
> I watched fosdem talk about
> nbdkit... https://www.youtube.com/watch?v=9E5A608xJG0 . Nice. But word
> of warning: I'm not sure using it read-write on localhost is safe.
>
> In particular, user application could create a lot of dirty data
> quickly. If there's not enough memory for nbdkit (or nbd-client or
> nbd-server), you might get a deadlock.
Thanks for the kind words about the talk. I've added Wouter Verhelst
& the NBD mailing list to CC. Although I did the talk because the
subject is interesting, how I actually use nbdkit / NBD is to talk to
qemu and that's where I have most experience and where we (Red Hat)
use it in production systems.
However in January I spent a lot of time exercising the NBD loop-mount
+ nbdkit case using fio in order to find contention / bottlenecks in
our use of threads and locks. I didn't notice any particular problems
then, but it's possible my testing wasn't thorough enough. Or that
fio only creates small numbers of dirty pages (because of locality in
its access patterns I guess?)
When you say it's not safe, what could happen? What would we observe
if it was going wrong?
> Also note that nbd.txt in Documentation/blockdev/ points to
> sourceforge; it should probably point to
> https://github.com/NetworkBlockDevice/nbd ?
Wouter should be able to say what the correct link should be.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
next prev parent reply other threads:[~2019-02-15 22:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-15 19:19 nbd, nbdkit, loopback mounts and memory management Pavel Machek
2019-02-15 22:41 ` Richard W.M. Jones [this message]
2019-02-15 22:53 ` Richard W.M. Jones
2019-02-16 8:16 ` Wouter Verhelst
2019-02-15 22:55 ` Pavel Machek
2019-11-17 16:58 ` Richard W.M. Jones
2019-02-17 8:44 ` Richard W.M. Jones
2019-02-17 23:15 ` Pavel Machek
2019-02-17 23:51 ` Richard W.M. Jones
[not found] ` <CAM1OiDOKJ3SGHABNooQPFfx3KMYepYmSPxwyZZjZERc_y9v1WA@mail.gmail.com>
2019-03-12 16:14 ` Shaun McDowell
2019-03-12 16:14 ` Shaun McDowell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190215224126.GX12500@redhat.com \
--to=rjones@redhat.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nbd@other.debian.org \
--cc=pavel@ucw.cz \
--cc=w@uter.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.