qemu-devel
[Top][All Lists]
Advanced

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

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


From: Max Reitz
Subject: Re: [PATCH 02/18] fuse: Allow exporting BDSs via FUSE
Date: Mon, 6 Jan 2020 13:00:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]