All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: Hanna Czenczek <hreitz@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-doc@vger.kernel.org, virtualization@lists.linux.dev,
	"Miklos Szeredi" <mszeredi@redhat.com>,
	"German Maglione" <gmaglione@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Vivek Goyal" <vgoyal@redhat.com>
Subject: Re: [PATCH 0/2] virtio-fs: Add 'file' mount option
Date: Wed, 10 Jul 2024 14:42:22 -0400	[thread overview]
Message-ID: <20240710184222.GA1167307@perftesting> (raw)
In-Reply-To: <8ebfc48f-9a93-45ed-ba88-a4e4447d997a@redhat.com>

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

  reply	other threads:[~2024-07-10 18:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-09 11:19 [PATCH 0/2] virtio-fs: Add 'file' mount option Hanna Czenczek
2024-07-09 11:19 ` [PATCH 1/2] " Hanna Czenczek
2024-07-09 11:19 ` [PATCH 2/2] virtio-fs: Document " Hanna Czenczek
2024-07-09 17:56 ` [PATCH 0/2] virtio-fs: Add " Josef Bacik
2024-07-10  7:28   ` Hanna Czenczek
2024-07-10 18:42     ` Josef Bacik [this message]
2024-07-11  8:21       ` Hanna Czenczek
2024-07-11 14:27         ` Hanna Czenczek
2024-07-11 14:34         ` Josef Bacik
2024-07-11 15:04           ` Hanna Czenczek
2024-07-10 17:28 ` Stefan Hajnoczi
2024-07-11  8:31   ` Hanna Czenczek
2024-08-29  8:07 ` Miklos Szeredi
2024-08-29 12:37   ` Hanna Czenczek
2024-08-29 13:07     ` Miklos Szeredi
     [not found]       ` <b82dd5f9-a214-4a13-b500-38b07f1e9761@redhat.com>
2024-08-29 13:21         ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240710184222.GA1167307@perftesting \
    --to=josef@toxicpanda.com \
    --cc=corbet@lwn.net \
    --cc=eperezma@redhat.com \
    --cc=gmaglione@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=virtualization@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.