linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alyssa Ross <hi@alyssa.is>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, virtio-fs@redhat.com,
	miklos@szeredi.hu, stefanha@redhat.com, mzxreary@0pointer.de,
	gmaglione@redhat.com
Subject: Re: [PATCH] virtiofs: Export filesystem tags through sysfs
Date: Thu, 09 Nov 2023 16:57:01 +0100	[thread overview]
Message-ID: <87r0ky538y.fsf@alyssa.is> (raw)
In-Reply-To: <ZUv56DRM/aiBRspd@redhat.com>

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

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.

> 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: 832 bytes --]

  reply	other threads:[~2023-11-09 15:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05 20:30 [PATCH] virtiofs: Export filesystem tags through sysfs Vivek Goyal
2023-10-09  9:53 ` Miklos Szeredi
2023-10-09 20:21   ` [Virtio-fs] " Vivek Goyal
2023-11-11 11:52     ` Greg KH
2023-10-10 17:21 ` Stefan Hajnoczi
2023-10-11 18:08   ` German Maglione
2023-10-21 16:10 ` Alyssa Ross
2023-11-08 21:13   ` Vivek Goyal
2023-11-09 15:57     ` Alyssa Ross [this message]
2023-11-12 10:10       ` Stefan Hajnoczi
2023-11-11 11:53 ` Greg KH
2024-01-05 20:44   ` Vivek Goyal
2024-01-06  7:02     ` Greg KH

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=87r0ky538y.fsf@alyssa.is \
    --to=hi@alyssa.is \
    --cc=gmaglione@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mzxreary@0pointer.de \
    --cc=stefanha@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=virtio-fs@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).