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

Re: [Libguestfs] [nbdkit PATCH 5/5] ext2: Support parallel requests and connections

On Thu, May 06, 2021 at 08:59:40PM -0500, Eric Blake wrote:
> Instead of serializing connections (which in turn serializes requests)
> because it is unsafe to open more than one handle into the filesystem
> at the same time, use the recently-added APIs to open the filesystem
> during .after_fork, then use the fact that ext2 code then supports
> parallel access to files within the single system handle.


> +/* Opening more than one instance of the filesystem in parallel is a
> + * recipe for disaster, so instead we open a single instance during
> + * after_fork to share among all client connections.  If the
> + * underlying plugin supports parallel requests, then we do too since
> + * ext2 code is re-entrant through our one open handle.
> + */
> +static int
> +ext2_after_fork (nbdkit_backend *nxdata)
> +{
> +  CLEANUP_FREE char *name = NULL;
> +  int fs_flags;
> +  int64_t r;
> +  errcode_t err;
> +
> +  /* It would be desirable for ‘nbdkit -r’ to behave the same way as
> +   * ‘mount -o ro’.  But we don't know the state of the readonly flag
> +   * until ext2_open is called, so for now we can't do that.  We could
> +   * add a knob during .config if desired; but until then, we blindly
> +   * request write access to the underlying plugin, for journal
> +   * replay.
> +   *
> +   * Similarly, there is no sane way to pass the client's exportname
> +   * through to the plugin (whether or not .config was set to serve a
> +   * single file or to let the client choose by exportname), so
> +   * blindly ask for "" and rely on the plugin's default.
> +   */

I feel we ought to try to fix this before applying this patch.

Since it's a filter, could we not pass the global readonly flag as a
parameter to after_fork?  (Or allow filters to read the global flag I
suppose, but ... yuck ...)

Or we should add the extra ext2readonly=true|false parameter.  Which
might be the easiest and most predictable way to fix this.  There's
even a case where you might use -r + writable ext2 with some kind of
implausible reverse cow filter.


Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch

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