Development discussions about virtio-fs
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Alyssa Ross <hi@alyssa.is>
Cc: Vivek Goyal <vgoyal@redhat.com>,
	linux-fsdevel@vger.kernel.org, virtio-fs@lists.linux.dev,
	miklos@szeredi.hu, mzxreary@0pointer.de, gmaglione@redhat.com
Subject: Re: [PATCH] virtiofs: Export filesystem tags through sysfs
Date: Sun, 12 Nov 2023 18:10:41 +0800	[thread overview]
Message-ID: <20231112101041.GB207186@fedora> (raw)
In-Reply-To: <87r0ky538y.fsf@alyssa.is>

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

On Thu, Nov 09, 2023 at 04:57:01PM +0100, Alyssa Ross wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Sat, Oct 21, 2023 at 04:10:21PM +0000, Alyssa Ross wrote:
> >> Are you still thinking about exposing this in the uevent as well?
> >> That would be much more convenient for me, because with this approach
> >> by the time the "remove" uevent arrives, it's no longer possible to
> >> check what tag was associated with the device — you have to store it
> >> somewhere when the device appears, so you can look it up again when the
> >> device is removed.  (Not everybody uses udev.)
> >
> > Looks like systemd + udev combination can already take care of it. I just
> > had to specify "StopWhenUnneeded=true" in my systemd .mount unit file. And
> > that made sure that when device goes away, virtiofs is unmounted and
> > service is deactivated.
> 
> My point is that, if it's not exposed in the uevent, the tag information
> has to be tracked somehow.  systemd/udev may do that already, but every
> other system people might be using (mine uses mdevd) also has to track
> that state.  Whereas if the uevent did contain that information,
> userspace would be able to do the unmount directly, without needing to
> look up some information it has previously saved.
> 
> Relying on tracking state from previous events also introduces potential
> reliability problems — it's possible to miss uevents if the netlink
> queue fills up.  Suppose I have a system where virtiofs filesystems
> should always be unmounted when the device goes away.  I miss the uevent
> for the device being added, the user mounts the filesystem anyway, and
> then when the device removal uevent comes in, unless that uevent
> contains the filesystem tag, I'm not going to know which filesystem to
> unmount.

I agree that it's hard for userspace to react when a virtiofs device is
removed. Looking at the Linux device remove code, it appears the sysfs
attr is already gone when the UNBIND event is emitted.

My naive idea as a sysfs newbie is that the driver's ->remove() should
be able to produce an envp[] argument to the later kobject_uevent_env()
call. This would allow the driver to pass additional information to
userspace. Then the virtiofs driver could include the tag string in the
UNBIND event.

I'm a bit surprised that this functionality doesn't already exist. Maybe
there is another way of solving this?

(A different approach that feels wrong is to leave the "tag" attr on the
virtio device and just make sure it gets cleaned up when the virtio bus
driver removes the device kobj. That way unbind udev rules could
continue to use the sysfs attr.)

Stefan

> 
> > Following is my mount unit file.
> >
> > $ cat /etc/systemd/system/mnt-virtiofs.mount
> >
> > [Unit]
> > Description=Virtiofs mount myfs
> > DefaultDependencies=no
> > ConditionPathExists=/mnt/virtiofs
> > ConditionCapability=CAP_SYS_ADMIN
> > Before=sysinit.target
> > StopWhenUnneeded=true 
> >
> > [Mount]
> > What=myfs
> > Where=/mnt/virtiofs
> > Type=virtiofs
> >
> > And following is the udev rule I used.
> >
> > $ cat /etc/udev/rules.d/80-local.rules
> > SUBSYSTEM=="virtio", DRIVER=="virtiofs", ATTR{tag}=="myfs", TAG+="systemd", ENV{SYSTEMD_WANTS}+="mnt-virtiofs.mount"
> >
> > And a combination of above two seems to work. virtiofs is automatically
> > mounted when device is hotplugged and it is unmounted when device is
> > hot unplugged.



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

      parent reply	other threads:[~2023-11-12 17:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05 20:30 [Virtio-fs] [PATCH] virtiofs: Export filesystem tags through sysfs Vivek Goyal
2023-10-09  9:53 ` Miklos Szeredi
2023-10-09 20:21   ` Vivek Goyal
2023-10-10 17:21 ` Stefan Hajnoczi
2023-10-11 18:08   ` German Maglione
2023-10-21 16:10 ` Alyssa Ross
     [not found]   ` <ZUv56DRM/aiBRspd@redhat.com>
     [not found]     ` <87r0ky538y.fsf@alyssa.is>
2023-11-12 10:10       ` Stefan Hajnoczi [this message]

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=20231112101041.GB207186@fedora \
    --to=stefanha@redhat.com \
    --cc=gmaglione@redhat.com \
    --cc=hi@alyssa.is \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mzxreary@0pointer.de \
    --cc=vgoyal@redhat.com \
    --cc=virtio-fs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox