[PATCH 0/2] virtio-fs: Add 'file' mount option

[PATCH 0/2] virtio-fs: Add 'file' mount option

[Hanna Czenczek]

Hi,

We want to be able to mount filesystems that just consist of one regular
file via virtio-fs, i.e. no root directory, just a file as the root
node.

While that is possible via FUSE itself (through the 'rootmode' mount
option, which is automatically set by the fusermount help program to
match the mount point's inode mode), there is no virtio-fs option yet
that would allow changing the rootmode from S_IFDIR to S_IFREG.

To do that, this series introduces a new 'file' mount option that does
precisely that.  Alternatively, we could provide the same 'rootmode'
option that FUSE has, but as laid out in patch 1's commit description,
that option is a bit cumbersome for virtio-fs (in a way that it is not
for FUSE), and its usefulness as a more general option is limited.


Hanna Czenczek (2):
  virtio-fs: Add 'file' mount option
  virtio-fs: Document 'file' mount option

 fs/fuse/virtio_fs.c                    | 9 ++++++++-
 Documentation/filesystems/virtiofs.rst | 5 ++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

-- 
2.45.1

[PATCH 1/2] virtio-fs: Add 'file' mount option

[Hanna Czenczek]

This new option allows mounting filesystems whose root node is a regular
file instead of a directory.

FUSE itself has the more generic 'rootmode' option, which theoretically
allows mounting filesystems with an even greater variety of root node
modes.  There are two reasons why we do not let virtio-fs provide that
same option:

First, with FUSE, this option is supposed to be set automatically by
e.g. the fusermount helper program to match the root node's mode, no
user involvement necessary.  It is easy for fusermount to stat() the
mount point (whose mode must match the filesystem's root node mode) and
fill the 'rootmode' option appropriately.  In the case of virtio-fs,
however, mounting is often done manually by the user, there is no helper
program; and I as a user find the simple '-o file' preferable over the
more cryptic '-o rootmode=0100000'.

Second, inode modes other than S_IFDIR and S_IFREG have limited use with
virtio-fs anyway:
- Device files are host-specific, so passing them via virtio-fs from
  host to guest (or between different guests) seems rarely useful,
- FIFOs and Unix domain sockets currently do not allow communication
  between guest and host (or between different guests), which is really
  the only reason why they would be used as virtio-fs filesystem root
  nodes,
- and symlinks in general do not make much sense as filesystem root
  nodes.

The more generic 'rootmode' option is therefore not very useful for
virtio-fs, while being harder to use.

Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
---
 fs/fuse/virtio_fs.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index 1a52a51b6b07..ba1a6ac31000 100644
--- a/fs/fuse/virtio_fs.c
+++ b/fs/fuse/virtio_fs.c
@@ -107,11 +107,13 @@ static const struct constant_table dax_param_enums[] = {
 enum {
 	OPT_DAX,
 	OPT_DAX_ENUM,
+	OPT_FILE,
 };
 
 static const struct fs_parameter_spec virtio_fs_parameters[] = {
 	fsparam_flag("dax", OPT_DAX),
 	fsparam_enum("dax", OPT_DAX_ENUM, dax_param_enums),
+	fsparam_flag("file", OPT_FILE),
 	{}
 };
 
@@ -133,6 +135,10 @@ static int virtio_fs_parse_param(struct fs_context *fsc,
 	case OPT_DAX_ENUM:
 		ctx->dax_mode = result.uint_32;
 		break;
+	case OPT_FILE:
+		ctx->rootmode = S_IFREG;
+		ctx->rootmode_present = true;
+		break;
 	default:
 		return -EINVAL;
 	}
@@ -1401,7 +1407,8 @@ static const struct fuse_iqueue_ops virtio_fs_fiq_ops = {
 
 static inline void virtio_fs_ctx_set_defaults(struct fuse_fs_context *ctx)
 {
-	ctx->rootmode = S_IFDIR;
+	if (!ctx->rootmode_present)
+		ctx->rootmode = S_IFDIR;
 	ctx->default_permissions = 1;
 	ctx->allow_other = 1;
 	ctx->max_read = UINT_MAX;
-- 
2.45.1

[PATCH 2/2] virtio-fs: Document 'file' mount option

[Hanna Czenczek]

Add the new mount option to the virtio-fs documentation.

While at it, remove the note that virtio-fs would support FUSE mount
options, because it does not.

Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
---
 Documentation/filesystems/virtiofs.rst | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/filesystems/virtiofs.rst b/Documentation/filesystems/virtiofs.rst
index fd4d2484e949..201ac9ee13c5 100644
--- a/Documentation/filesystems/virtiofs.rst
+++ b/Documentation/filesystems/virtiofs.rst
@@ -43,7 +43,10 @@ Mount options
 -------------
 
 virtiofs supports general VFS mount options, for example, remount,
-ro, rw, context, etc. It also supports FUSE mount options.
+ro, rw, context, etc.
+
+The ``file`` mount option allows mounting a filesystem whose root node is not a
+directory but a regular file.
 
 atime behavior
 ^^^^^^^^^^^^^^
-- 
2.45.1

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Josef Bacik]

On Tue, Jul 09, 2024 at 01:19:16PM +0200, Hanna Czenczek wrote:
> Hi,
> 
> We want to be able to mount filesystems that just consist of one regular
> file via virtio-fs, i.e. no root directory, just a file as the root
> node.
> 
> While that is possible via FUSE itself (through the 'rootmode' mount
> option, which is automatically set by the fusermount help program to
> match the mount point's inode mode), there is no virtio-fs option yet
> that would allow changing the rootmode from S_IFDIR to S_IFREG.
> 
> To do that, this series introduces a new 'file' mount option that does
> precisely that.  Alternatively, we could provide the same 'rootmode'
> option that FUSE has, but as laid out in patch 1's commit description,
> that option is a bit cumbersome for virtio-fs (in a way that it is not
> for FUSE), and its usefulness as a more general option is limited.
> 

All this does is make file an alias for something a little easier for users to
read, which can easily be done in libfuse.  Add the code to lib/mount.c to alias
'file' to turn it into rootmode=S_IFREG when it sends it to the kernel, it's not
necessary to do this in the kernel.  Thanks,

Josef

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Hanna Czenczek]

On 09.07.24 19:56, Josef Bacik wrote:
> On Tue, Jul 09, 2024 at 01:19:16PM +0200, Hanna Czenczek wrote:
>> Hi,
>>
>> We want to be able to mount filesystems that just consist of one regular
>> file via virtio-fs, i.e. no root directory, just a file as the root
>> node.
>>
>> While that is possible via FUSE itself (through the 'rootmode' mount
>> option, which is automatically set by the fusermount help program to
>> match the mount point's inode mode), there is no virtio-fs option yet
>> that would allow changing the rootmode from S_IFDIR to S_IFREG.
>>
>> To do that, this series introduces a new 'file' mount option that does
>> precisely that.  Alternatively, we could provide the same 'rootmode'
>> option that FUSE has, but as laid out in patch 1's commit description,
>> that option is a bit cumbersome for virtio-fs (in a way that it is not
>> for FUSE), and its usefulness as a more general option is limited.
>>
> All this does is make file an alias for something a little easier for users to
> read, which can easily be done in libfuse.  Add the code to lib/mount.c to alias
> 'file' to turn it into rootmode=S_IFREG when it sends it to the kernel, it's not
> necessary to do this in the kernel.  Thanks,

This series is not about normal FUSE filesystems (file_system_type 
fuse_fs_type, “fuse”), but about virtio-fs (file_system_type 
virtio_fs_type, “virtiofs”), i.e. a case where libfuse and fusermount 
are not involved at all.  As far as I’m aware, mounting a virtio-fs 
filesystem with a non-directory root inode is currently not possible at all.

Hanna

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Josef Bacik]

On Wed, Jul 10, 2024 at 09:28:08AM +0200, Hanna Czenczek wrote:
> On 09.07.24 19:56, Josef Bacik wrote:
> > On Tue, Jul 09, 2024 at 01:19:16PM +0200, Hanna Czenczek wrote:
> > > Hi,
> > > 
> > > We want to be able to mount filesystems that just consist of one regular
> > > file via virtio-fs, i.e. no root directory, just a file as the root
> > > node.
> > > 
> > > While that is possible via FUSE itself (through the 'rootmode' mount
> > > option, which is automatically set by the fusermount help program to
> > > match the mount point's inode mode), there is no virtio-fs option yet
> > > that would allow changing the rootmode from S_IFDIR to S_IFREG.
> > > 
> > > To do that, this series introduces a new 'file' mount option that does
> > > precisely that.  Alternatively, we could provide the same 'rootmode'
> > > option that FUSE has, but as laid out in patch 1's commit description,
> > > that option is a bit cumbersome for virtio-fs (in a way that it is not
> > > for FUSE), and its usefulness as a more general option is limited.
> > > 
> > All this does is make file an alias for something a little easier for users to
> > read, which can easily be done in libfuse.  Add the code to lib/mount.c to alias
> > 'file' to turn it into rootmode=S_IFREG when it sends it to the kernel, it's not
> > necessary to do this in the kernel.  Thanks,
> 
> This series is not about normal FUSE filesystems (file_system_type
> fuse_fs_type, “fuse”), but about virtio-fs (file_system_type virtio_fs_type,
> “virtiofs”), i.e. a case where libfuse and fusermount are not involved at
> all.  As far as I’m aware, mounting a virtio-fs filesystem with a
> non-directory root inode is currently not possible at all.

Ok so I think I had it backwards in my head, my apologies.

That being said I still don't understand why this requires a change to virtiofs
at all.

I have a virtiofs thing attached to my VM.  Inside the vm I do

mount -t virtiofs <name of thing I've attached to the vm> /directory

and then on the host machine, virtiofsd is a "normal" FUSE driver, except it's
talking over the socket you setup between the guest and the host.  I assume this
is all correct?

So then the question is, why does it matter what virtiofsd is exposing?  I guess
that's the better question.  The guest shouldn't have to care if it's a
directory or a file right?  The mountpoint is going to be a directory, whatever
is backing it shouldn't matter.  Could you describe the exact thing you're
trying to accomplish?  Thanks,

Josef

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Hanna Czenczek]

On 10.07.24 20:42, Josef Bacik wrote:
> On Wed, Jul 10, 2024 at 09:28:08AM +0200, Hanna Czenczek wrote:
>> On 09.07.24 19:56, Josef Bacik wrote:
>>> On Tue, Jul 09, 2024 at 01:19:16PM +0200, Hanna Czenczek wrote:
>>>> Hi,
>>>>
>>>> We want to be able to mount filesystems that just consist of one regular
>>>> file via virtio-fs, i.e. no root directory, just a file as the root
>>>> node.
>>>>
>>>> While that is possible via FUSE itself (through the 'rootmode' mount
>>>> option, which is automatically set by the fusermount help program to
>>>> match the mount point's inode mode), there is no virtio-fs option yet
>>>> that would allow changing the rootmode from S_IFDIR to S_IFREG.
>>>>
>>>> To do that, this series introduces a new 'file' mount option that does
>>>> precisely that.  Alternatively, we could provide the same 'rootmode'
>>>> option that FUSE has, but as laid out in patch 1's commit description,
>>>> that option is a bit cumbersome for virtio-fs (in a way that it is not
>>>> for FUSE), and its usefulness as a more general option is limited.
>>>>
>>> All this does is make file an alias for something a little easier for users to
>>> read, which can easily be done in libfuse.  Add the code to lib/mount.c to alias
>>> 'file' to turn it into rootmode=S_IFREG when it sends it to the kernel, it's not
>>> necessary to do this in the kernel.  Thanks,
>> This series is not about normal FUSE filesystems (file_system_type
>> fuse_fs_type, “fuse”), but about virtio-fs (file_system_type virtio_fs_type,
>> “virtiofs”), i.e. a case where libfuse and fusermount are not involved at
>> all.  As far as I’m aware, mounting a virtio-fs filesystem with a
>> non-directory root inode is currently not possible at all.
> Ok so I think I had it backwards in my head, my apologies.
>
> That being said I still don't understand why this requires a change to virtiofs
> at all.
>
> I have a virtiofs thing attached to my VM.  Inside the vm I do
>
> mount -t virtiofs <name of thing I've attached to the vm> /directory
>
> and then on the host machine, virtiofsd is a "normal" FUSE driver, except it's
> talking over the socket you setup between the guest and the host.  I assume this
> is all correct?
>
> So then the question is, why does it matter what virtiofsd is exposing?  I guess
> that's the better question.  The guest shouldn't have to care if it's a
> directory or a file right?  The mountpoint is going to be a directory, whatever
> is backing it shouldn't matter.  Could you describe the exact thing you're
> trying to accomplish?  Thanks,

The mount point needs to be of the same mode as the root node of the 
mounted filesystem, or it’ll be inaccessible after mounting[1].  In this 
case, I want to export a regular file as the root node, so the root node 
must be a regular file, too:

host$ echo foo > /tmp/bar

host$ virtiofsd --shared-dir /tmp/bar --socket-path /tmp/viofsd.sock 
--sandbox none


guest# mkdir /tmp/mnt-dir

guest# mount -t virtiofs virtiofs-tag /tmp/mnt-dir

guest# stat /tmp/mnt-dir
stat: cannot statx '/tmp/mnt-dir': Input/output error

guest# cat /tmp/mnt-dir
cat: /tmp/mnt-dir: Input/output error

guest# ls /tmp/mnt-dir
ls: cannot access '/tmp/mnt-dir': Input/output error

guest# umount /tmp/mnt-dir

(following with this series applied)

guest# touch /tmp/mnt-file

guest# mount -t virtiofs virtiofs-tag /tmp/mnt-file -o file

guest# stat /tmp/mnt-file
   File: /tmp/mnt-file
   Size: 4               Blocks: 8          IO Block: 4096   regular file
[...]

guest# cat /tmp/mnt-file
foo

guest# ls --file-type /tmp/mnt-file
/tmp/mnt-file

guest# ls --file-type /tmp
mnt-dir/
mnt-file
[...]


[1] As far as I remember, FUSE/virtio-fs will present the root node’s 
mode as 'rootmode' during mounting, and so the d_is_dir() equality 
checks in do_move_mount() and graft_tree() just check whether that 
matches the mount point’s mode.  So, like in the example above, mounting 
a filesystem whose root node is a regular file to a directory mount 
point without '-o file' succeeds.  But accessing it then fails, probably 
because the mismatch is then noticed somewhere (virtiofsd receives a 
GETATTR request, that’s it), i.e. the root node is supposed to be a 
directory, but it turns out not to be after all.

Hanna

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Hanna Czenczek]

On 11.07.24 10:21, Hanna Czenczek wrote:
> On 10.07.24 20:42, Josef Bacik wrote:

[...]

>> So then the question is, why does it matter what virtiofsd is 
>> exposing?  I guess
>> that's the better question.  The guest shouldn't have to care if it's a
>> directory or a file right?  The mountpoint is going to be a 
>> directory, whatever
>> is backing it shouldn't matter.  Could you describe the exact thing 
>> you're
>> trying to accomplish?  Thanks,
>
> The mount point needs to be of the same mode as the root node of the 
> mounted filesystem, or it’ll be inaccessible after mounting[1].  In 
> this case, I want to export a regular file as the root node, so the 
> root node must be a regular file, too:

Sorry, I meant “[…], so the mount point must be a regular file, too”.

Hanna

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Josef Bacik]

On Thu, Jul 11, 2024 at 10:21:35AM +0200, Hanna Czenczek wrote:
> On 10.07.24 20:42, Josef Bacik wrote:
> > On Wed, Jul 10, 2024 at 09:28:08AM +0200, Hanna Czenczek wrote:
> > > On 09.07.24 19:56, Josef Bacik wrote:
> > > > On Tue, Jul 09, 2024 at 01:19:16PM +0200, Hanna Czenczek wrote:
> > > > > Hi,
> > > > > 
> > > > > We want to be able to mount filesystems that just consist of one regular
> > > > > file via virtio-fs, i.e. no root directory, just a file as the root
> > > > > node.
> > > > > 
> > > > > While that is possible via FUSE itself (through the 'rootmode' mount
> > > > > option, which is automatically set by the fusermount help program to
> > > > > match the mount point's inode mode), there is no virtio-fs option yet
> > > > > that would allow changing the rootmode from S_IFDIR to S_IFREG.
> > > > > 
> > > > > To do that, this series introduces a new 'file' mount option that does
> > > > > precisely that.  Alternatively, we could provide the same 'rootmode'
> > > > > option that FUSE has, but as laid out in patch 1's commit description,
> > > > > that option is a bit cumbersome for virtio-fs (in a way that it is not
> > > > > for FUSE), and its usefulness as a more general option is limited.
> > > > > 
> > > > All this does is make file an alias for something a little easier for users to
> > > > read, which can easily be done in libfuse.  Add the code to lib/mount.c to alias
> > > > 'file' to turn it into rootmode=S_IFREG when it sends it to the kernel, it's not
> > > > necessary to do this in the kernel.  Thanks,
> > > This series is not about normal FUSE filesystems (file_system_type
> > > fuse_fs_type, “fuse”), but about virtio-fs (file_system_type virtio_fs_type,
> > > “virtiofs”), i.e. a case where libfuse and fusermount are not involved at
> > > all.  As far as I’m aware, mounting a virtio-fs filesystem with a
> > > non-directory root inode is currently not possible at all.
> > Ok so I think I had it backwards in my head, my apologies.
> > 
> > That being said I still don't understand why this requires a change to virtiofs
> > at all.
> > 
> > I have a virtiofs thing attached to my VM.  Inside the vm I do
> > 
> > mount -t virtiofs <name of thing I've attached to the vm> /directory
> > 
> > and then on the host machine, virtiofsd is a "normal" FUSE driver, except it's
> > talking over the socket you setup between the guest and the host.  I assume this
> > is all correct?
> > 
> > So then the question is, why does it matter what virtiofsd is exposing?  I guess
> > that's the better question.  The guest shouldn't have to care if it's a
> > directory or a file right?  The mountpoint is going to be a directory, whatever
> > is backing it shouldn't matter.  Could you describe the exact thing you're
> > trying to accomplish?  Thanks,
> 
> The mount point needs to be of the same mode as the root node of the mounted
> filesystem, or it’ll be inaccessible after mounting[1].  In this case, I
> want to export a regular file as the root node, so the root node must be a
> regular file, too:
> 
> host$ echo foo > /tmp/bar
> 
> host$ virtiofsd --shared-dir /tmp/bar --socket-path /tmp/viofsd.sock
> --sandbox none
> 
> 
> guest# mkdir /tmp/mnt-dir
> 
> guest# mount -t virtiofs virtiofs-tag /tmp/mnt-dir
> 
> guest# stat /tmp/mnt-dir
> stat: cannot statx '/tmp/mnt-dir': Input/output error
> 
> guest# cat /tmp/mnt-dir
> cat: /tmp/mnt-dir: Input/output error
> 
> guest# ls /tmp/mnt-dir
> ls: cannot access '/tmp/mnt-dir': Input/output error
> 
> guest# umount /tmp/mnt-dir
> 
> (following with this series applied)
> 
> guest# touch /tmp/mnt-file
> 
> guest# mount -t virtiofs virtiofs-tag /tmp/mnt-file -o file
> 
> guest# stat /tmp/mnt-file
>   File: /tmp/mnt-file
>   Size: 4               Blocks: 8          IO Block: 4096   regular file
> [...]
> 
> guest# cat /tmp/mnt-file
> foo
> 
> guest# ls --file-type /tmp/mnt-file
> /tmp/mnt-file
> 
> guest# ls --file-type /tmp
> mnt-dir/
> mnt-file
> [...]
> 

Got it, this makes sense, thanks for explaining it to me.  You can add

Reviewed-by: Josef Bacik <josef@toxicpanda.com>

Thanks,

Josef

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Hanna Czenczek]

On 11.07.24 16:34, Josef Bacik wrote:
> On Thu, Jul 11, 2024 at 10:21:35AM +0200, Hanna Czenczek wrote:
>> On 10.07.24 20:42, Josef Bacik wrote:
>>> On Wed, Jul 10, 2024 at 09:28:08AM +0200, Hanna Czenczek wrote:
>>>> On 09.07.24 19:56, Josef Bacik wrote:
>>>>> On Tue, Jul 09, 2024 at 01:19:16PM +0200, Hanna Czenczek wrote:
>>>>>> Hi,
>>>>>>
>>>>>> We want to be able to mount filesystems that just consist of one regular
>>>>>> file via virtio-fs, i.e. no root directory, just a file as the root
>>>>>> node.
>>>>>>
>>>>>> While that is possible via FUSE itself (through the 'rootmode' mount
>>>>>> option, which is automatically set by the fusermount help program to
>>>>>> match the mount point's inode mode), there is no virtio-fs option yet
>>>>>> that would allow changing the rootmode from S_IFDIR to S_IFREG.
>>>>>>
>>>>>> To do that, this series introduces a new 'file' mount option that does
>>>>>> precisely that.  Alternatively, we could provide the same 'rootmode'
>>>>>> option that FUSE has, but as laid out in patch 1's commit description,
>>>>>> that option is a bit cumbersome for virtio-fs (in a way that it is not
>>>>>> for FUSE), and its usefulness as a more general option is limited.
>>>>>>
>>>>> All this does is make file an alias for something a little easier for users to
>>>>> read, which can easily be done in libfuse.  Add the code to lib/mount.c to alias
>>>>> 'file' to turn it into rootmode=S_IFREG when it sends it to the kernel, it's not
>>>>> necessary to do this in the kernel.  Thanks,
>>>> This series is not about normal FUSE filesystems (file_system_type
>>>> fuse_fs_type, “fuse”), but about virtio-fs (file_system_type virtio_fs_type,
>>>> “virtiofs”), i.e. a case where libfuse and fusermount are not involved at
>>>> all.  As far as I’m aware, mounting a virtio-fs filesystem with a
>>>> non-directory root inode is currently not possible at all.
>>> Ok so I think I had it backwards in my head, my apologies.
>>>
>>> That being said I still don't understand why this requires a change to virtiofs
>>> at all.
>>>
>>> I have a virtiofs thing attached to my VM.  Inside the vm I do
>>>
>>> mount -t virtiofs <name of thing I've attached to the vm> /directory
>>>
>>> and then on the host machine, virtiofsd is a "normal" FUSE driver, except it's
>>> talking over the socket you setup between the guest and the host.  I assume this
>>> is all correct?
>>>
>>> So then the question is, why does it matter what virtiofsd is exposing?  I guess
>>> that's the better question.  The guest shouldn't have to care if it's a
>>> directory or a file right?  The mountpoint is going to be a directory, whatever
>>> is backing it shouldn't matter.  Could you describe the exact thing you're
>>> trying to accomplish?  Thanks,
>> The mount point needs to be of the same mode as the root node of the mounted
>> filesystem, or it’ll be inaccessible after mounting[1].  In this case, I
>> want to export a regular file as the root node, so the root node must be a
>> regular file, too:
>>
>> host$ echo foo > /tmp/bar
>>
>> host$ virtiofsd --shared-dir /tmp/bar --socket-path /tmp/viofsd.sock
>> --sandbox none
>>
>>
>> guest# mkdir /tmp/mnt-dir
>>
>> guest# mount -t virtiofs virtiofs-tag /tmp/mnt-dir
>>
>> guest# stat /tmp/mnt-dir
>> stat: cannot statx '/tmp/mnt-dir': Input/output error
>>
>> guest# cat /tmp/mnt-dir
>> cat: /tmp/mnt-dir: Input/output error
>>
>> guest# ls /tmp/mnt-dir
>> ls: cannot access '/tmp/mnt-dir': Input/output error
>>
>> guest# umount /tmp/mnt-dir
>>
>> (following with this series applied)
>>
>> guest# touch /tmp/mnt-file
>>
>> guest# mount -t virtiofs virtiofs-tag /tmp/mnt-file -o file
>>
>> guest# stat /tmp/mnt-file
>>    File: /tmp/mnt-file
>>    Size: 4               Blocks: 8          IO Block: 4096   regular file
>> [...]
>>
>> guest# cat /tmp/mnt-file
>> foo
>>
>> guest# ls --file-type /tmp/mnt-file
>> /tmp/mnt-file
>>
>> guest# ls --file-type /tmp
>> mnt-dir/
>> mnt-file
>> [...]
>>
> Got it, this makes sense, thanks for explaining it to me.  You can add
>
> Reviewed-by: Josef Bacik <josef@toxicpanda.com>

Thanks!

Hanna

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

On Tue, Jul 09, 2024 at 01:19:16PM +0200, Hanna Czenczek wrote:
> Hi,
> 
> We want to be able to mount filesystems that just consist of one regular
> file via virtio-fs, i.e. no root directory, just a file as the root
> node.
> 
> While that is possible via FUSE itself (through the 'rootmode' mount
> option, which is automatically set by the fusermount help program to
> match the mount point's inode mode), there is no virtio-fs option yet
> that would allow changing the rootmode from S_IFDIR to S_IFREG.
> 
> To do that, this series introduces a new 'file' mount option that does
> precisely that.  Alternatively, we could provide the same 'rootmode'
> option that FUSE has, but as laid out in patch 1's commit description,
> that option is a bit cumbersome for virtio-fs (in a way that it is not
> for FUSE), and its usefulness as a more general option is limited.
> 
> 
> Hanna Czenczek (2):
>   virtio-fs: Add 'file' mount option
>   virtio-fs: Document 'file' mount option
> 
>  fs/fuse/virtio_fs.c                    | 9 ++++++++-
>  Documentation/filesystems/virtiofs.rst | 5 ++++-
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> -- 
> 2.45.1
> 

Looks good to me. Maybe add the 'file' option to FUSE as well to keep
them in sync (eventually rootmode could be exposed to virtiofs too, if
necessary)?

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Hanna Czenczek]

On 10.07.24 19:28, Stefan Hajnoczi wrote:
> On Tue, Jul 09, 2024 at 01:19:16PM +0200, Hanna Czenczek wrote:
>> Hi,
>>
>> We want to be able to mount filesystems that just consist of one regular
>> file via virtio-fs, i.e. no root directory, just a file as the root
>> node.
>>
>> While that is possible via FUSE itself (through the 'rootmode' mount
>> option, which is automatically set by the fusermount help program to
>> match the mount point's inode mode), there is no virtio-fs option yet
>> that would allow changing the rootmode from S_IFDIR to S_IFREG.
>>
>> To do that, this series introduces a new 'file' mount option that does
>> precisely that.  Alternatively, we could provide the same 'rootmode'
>> option that FUSE has, but as laid out in patch 1's commit description,
>> that option is a bit cumbersome for virtio-fs (in a way that it is not
>> for FUSE), and its usefulness as a more general option is limited.
>>
>>
>> Hanna Czenczek (2):
>>    virtio-fs: Add 'file' mount option
>>    virtio-fs: Document 'file' mount option
>>
>>   fs/fuse/virtio_fs.c                    | 9 ++++++++-
>>   Documentation/filesystems/virtiofs.rst | 5 ++++-
>>   2 files changed, 12 insertions(+), 2 deletions(-)
>>
>> -- 
>> 2.45.1
>>
> Looks good to me. Maybe add the 'file' option to FUSE as well to keep
> them in sync (eventually rootmode could be exposed to virtiofs too, if
> necessary)?

I don’t think this option makes much sense for FUSE, like Josef has 
said; it would just duplicate a subset of 'rootmode', and because FUSE 
filesystems are rarely mounted by hand, I don’t think anyone would ever 
use it.

If it were important to keep them in sync, I’d rather have virtio-fs 
provide 'rootmode' instead.  Personally, I don’t think it’s that 
important, and I’d rather have a simple '-o file' instead of '-o 
rootmode=0100000' (hope I counted the 0s right) for a filesystem that is 
actually not rarely mounted by hand.

If we ever do find out that we want to support other root modes than 
S_IFREG and S_IFDIR, we will probably want 'rootmode' for virtio-fs, 
too, yes.  But I can’t see that right now.

> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Thanks!

Hanna

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Miklos Szeredi]

On Tue, 9 Jul 2024 at 13:19, Hanna Czenczek <hreitz@redhat.com> wrote:
>
> Hi,
>
> We want to be able to mount filesystems that just consist of one regular
> file via virtio-fs, i.e. no root directory, just a file as the root
> node.
>
> While that is possible via FUSE itself (through the 'rootmode' mount
> option, which is automatically set by the fusermount help program to
> match the mount point's inode mode), there is no virtio-fs option yet
> that would allow changing the rootmode from S_IFDIR to S_IFREG.
>
> To do that, this series introduces a new 'file' mount option that does
> precisely that.  Alternatively, we could provide the same 'rootmode'
> option that FUSE has, but as laid out in patch 1's commit description,
> that option is a bit cumbersome for virtio-fs (in a way that it is not
> for FUSE), and its usefulness as a more general option is limited.

I wonder if this is needed at all for virtiofs, which could easily do
the FUSE_INIT request synchronously with mount(2) and the server could
just tell the client the root mode explicitly in the FUSE_INIT reply,
or could just fetch it with a separate FUSE_GETATTR.

Why regular fuse doesn't do this?  That's because a single threaded
server can only be supported if the mount(2) syscall returns before
any request need processing.  Virtiofs doesn't suffer from this at
all, AFAICS.

Does this make sense?

Thanks,
Miklos

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Hanna Czenczek]

On 29.08.24 10:07, Miklos Szeredi wrote:
> On Tue, 9 Jul 2024 at 13:19, Hanna Czenczek <hreitz@redhat.com> wrote:
>> Hi,
>>
>> We want to be able to mount filesystems that just consist of one regular
>> file via virtio-fs, i.e. no root directory, just a file as the root
>> node.
>>
>> While that is possible via FUSE itself (through the 'rootmode' mount
>> option, which is automatically set by the fusermount help program to
>> match the mount point's inode mode), there is no virtio-fs option yet
>> that would allow changing the rootmode from S_IFDIR to S_IFREG.
>>
>> To do that, this series introduces a new 'file' mount option that does
>> precisely that.  Alternatively, we could provide the same 'rootmode'
>> option that FUSE has, but as laid out in patch 1's commit description,
>> that option is a bit cumbersome for virtio-fs (in a way that it is not
>> for FUSE), and its usefulness as a more general option is limited.
> I wonder if this is needed at all for virtiofs, which could easily do
> the FUSE_INIT request synchronously with mount(2) and the server could
> just tell the client the root mode explicitly in the FUSE_INIT reply,
> or could just fetch it with a separate FUSE_GETATTR.

That would be great.  I thought it would be necessary to install the 
superblock before sending FUSE_INIT, so I thought this wasn’t possible.

I honestly have no idea how to go about it on a technical level, 
though.  Naïvely, I think we’d need to split off the tail of 
fuse_fill_super_common() (everything starting from the 
fuse_get_root_inode() call) into a separate function, which in case of 
virtio-fs we’d call once we get the FUSE_INIT reply.  (For 
non-virtio-fs, we could just call it immediately after 
fuse_fill_super_common().)

But we can’t return from fuse_fill_super() until that root node is set 
up, can we?  If so, we‘d need to await that FUSE_INIT reply in that 
function.  Can we do that?

> Why regular fuse doesn't do this?  That's because a single threaded
> server can only be supported if the mount(2) syscall returns before
> any request need processing.  Virtiofs doesn't suffer from this at
> all, AFAICS.
>
> Does this make sense?

It does!

Hanna

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Miklos Szeredi]

On Thu, 29 Aug 2024 at 14:37, Hanna Czenczek <hreitz@redhat.com> wrote:

> I honestly have no idea how to go about it on a technical level,
> though.  Naïvely, I think we’d need to split off the tail of
> fuse_fill_super_common() (everything starting from the
> fuse_get_root_inode() call) into a separate function, which in case of
> virtio-fs we’d call once we get the FUSE_INIT reply.  (For
> non-virtio-fs, we could just call it immediately after
> fuse_fill_super_common().)

Yes, except I'm not sure it needs to be split, that depends on whether
sending a request relies on any initialization in that function or
not.

> But we can’t return from fuse_fill_super() until that root node is set
> up, can we?  If so, we‘d need to await that FUSE_INIT reply in that
> function.  Can we do that?

Sure, just need to send FUSE_INIT with fuse_simple_request() instead
of fuse_simple_background().

Thanks,
Miklos

Re: [PATCH 0/2] virtio-fs: Add 'file' mount option

[Miklos Szeredi]

On Thu, 29 Aug 2024 at 15:11, Hanna Czenczek <hreitz@redhat.com> wrote:

> Hm, I thought we set some things in fuse_mount and fuse_conn in there that are then queried by fuse_send_init()...  Maybe the only thing fuse_send_init() needs is fm->sb->s_bdi->ra_pages for max_readahead.

Yes, that definitely needs special treatment.

> Sounds simple.  Do you think semantically it’s find to block here?  We’d only do it for virtio-fs, so a denial-of-service may not be of concern here.

It should be okay.  AFAIK all network filesystems block mount(2) until
setup is complete.

Thanks,
Miklos