[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE
From: |
Kevin Wolf |
Subject: |
Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE |
Date: |
Fri, 20 Dec 2019 12:24:02 +0100 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
Am 20.12.2019 um 11:48 hat Max Reitz geschrieben:
> On 20.12.19 11:26, Kevin Wolf wrote:
> > Am 19.12.2019 um 15:38 hat Max Reitz geschrieben:
> >> fuse-export-add allows mounting block graph nodes via FUSE on some
> >> existing regular file. That file should then appears like a raw disk
> >> image, and accesses to it result in accesses to the exported BDS.
> >>
> >> Right now, we only set up the mount point and tear all mount points down
> >> in bdrv_close_all(). We do not implement any access functions, so
> >> accessing the mount point only results in errors. This will be
> >> addressed by a followup patch.
> >>
> >> The set of exported nodes is kept in a hash table so we can later add a
> >> fuse-export-remove that allows unmounting.
> >>
> >> Signed-off-by: Max Reitz <address@hidden>
> >
> >> diff --git a/qapi/block.json b/qapi/block.json
> >> index 145c268bb6..03f8d1b537 100644
> >> --- a/qapi/block.json
> >> +++ b/qapi/block.json
> >> @@ -317,6 +317,29 @@
> >> ##
> >> { 'command': 'nbd-server-stop' }
> >>
> >> +##
> >> +# @fuse-export-add:
> >> +#
> >> +# Exports a block graph node on some (file) mountpoint as a raw image.
> >> +#
> >> +# @node-name: Node to be exported
> >> +#
> >> +# @mountpoint: Path on which to export the block device via FUSE.
> >> +# This must point to an existing regular file.
> >> +#
> >> +# @writable: Whether clients should be able to write to the block
> >> +# device via the FUSE export. (default: false)
> >> +#
> >> +# Since: 5.0
> >> +##
> >> +{ 'command': 'fuse-export-add',
> >> + 'data': {
> >> + 'node-name': 'str',
> >> + 'mountpoint': 'str',
> >> + '*writable': 'bool'
> >> + },
> >> + 'if': 'defined(CONFIG_FUSE)' }
> >
> > Can this use a BlockExport union from the start like I'm introducing in
> > the storage daemon series, together with a generic block-export-add?
>
> Hm, you mean still adding a FuseExport structure that would be part of
> BlockExport and then dropping fuse-export-add in favor of a
> block-export-add that we want anyway?
Yes.
> > It also looks like node-name and writable should be part of the common
> > base of BlockExport.
>
> node-name definitely, I’m not so sure about writable. Or, to be more
> precise, I think that if we want writable to be in the base, we also
> want growable to be there: Both are primarily options for the
> BlockBackend that the exports use.
>
> But both of course also need to be supported by the export
> implementation. nbd can make its BB growable all it wants, but that
> doesn’t make it work.
Right. Pragmatically, I think exports are very like to support writable,
but probably rather unlikely to support growable. So I do think there
would be a point for making writable part of the common base, but not
growable.
> So if we kept writable and growable in the common base, then the schema
> would give no information about what exports actually support them.
>
> On one hand, I don’t know whether it’s important to have this
> information in a static form, or whether it’s sufficient to learn at
> runtime.
>
> On the other, I don’t know whether it’s important to have those fields
> in the base or not. Would it make a difference on the wire?
Not for the command itself, so I think we're free to change it later. It
might make a difference for introspection, though, not sure. Markus?
Having it in the base might allow us to remove some duplication in the
code. Probably not much, though, so not too important.
> > Unfortunately this would mean that I can't use the
> > same BlockExportNbd for the existing nbd-server-add command any more. I
> > guess I could somehow get a shared base type for both, though.
>
> Hm. This sounds like you want to make it your problem. Can I take that
> to mean that you want to implement block-export-add and I can wait with
> v2 until that’s done? :-)
The NBD integration, yes. I already added the BlockExport type to my
patches, too, but I expect you would beat me to it. I'm not currently
planning to write a block-export-add because it doesn't add anything new
for the storage daemon, so FuseExport and the command this is your part.
The type currently only exists for --export.
Kevin
signature.asc
Description: PGP signature
- [PATCH 00/18] block: Allow exporting BDSs via FUSE, Max Reitz, 2019/12/19
- [PATCH 01/18] configure: Detect libfuse, Max Reitz, 2019/12/19
- [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Max Reitz, 2019/12/19
- Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Kevin Wolf, 2019/12/20
- Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Max Reitz, 2019/12/20
- Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE,
Kevin Wolf <=
- Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Max Reitz, 2019/12/20
- Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Markus Armbruster, 2019/12/20
- Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Kevin Wolf, 2019/12/20
- Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Markus Armbruster, 2019/12/20
- Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Eric Blake, 2019/12/20
- Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Markus Armbruster, 2019/12/20
- Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Kevin Wolf, 2019/12/20
Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE, Eric Blake, 2019/12/20
[PATCH 03/18] fuse: Implement standard FUSE operations, Max Reitz, 2019/12/19
[PATCH 04/18] fuse: Add fuse-export-remove, Max Reitz, 2019/12/19