Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1761 bytes --]

On 20.12.19 22:15, Eric Blake wrote:
> On 12/19/19 8:38 AM, Max Reitz wrote:
>> 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.
> 
> Before I review this, a quick question:
> 
> How does this compare to the recently added nbdfuse?
> https://www.redhat.com/archives/libguestfs/2019-October/msg00080.html

Hm.  Well, one thing is that it uses a file mount point instead of a
cumbersome directory + "ramdisk" file. O:-)  (Which, again, is fun
because this allows you to mount a qcow2 file on itself so it appears
like a raw image.)

Then we get all native block layer things without needing NBD support,
like resize (also growing on post-EOF writes).

(It also has features the nbdfuse patch mentions are not supported there
yet, i.e. fallocate() (zero writes and discards).  And I don’t suppose
nbdfuse supports lseek() yet either.  I suppose those features could be
added to nbdfuse, but, well, they are here now.)

> Or put another way, maybe we get the same effect by combining qemu-nbd
> with nbdfuse, but this new utility would cut out a middleman for more
> efficiency, right?

I would assume it has better efficiency, yes.  But the performance is
not very good anyway.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]