Announcement

Collapse
No announcement yet.

Mount Notification Support Still Coming Together For The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mount Notification Support Still Coming Together For The Linux Kernel

    Phoronix: Mount Notification Support Still Coming Together For The Linux Kernel

    David Howells of Red Hat continues striving for great improvements to Linux storage...

    http://www.phoronix.com/scan.php?pag...fications-2020

  • #2
    The kernel has had block &- device notification for ages.
    Can't see why a specific "mount notification" would be more valuable.

    Comment


    • #3
      Is udisks in the kernel yet?

      Comment


      • #4
        For a moment I thought this meant we might only be 10 or 15 years away from being able to remount an ejected USB device without physically replugging it, but then I realised this was just - well, actually, I STILL don't understand what the point of this is supposed to be. Yet another fsnotify-type layer, but just for devices?

        per milkylainen , anyone who can't already respond to the existing notifications competently probably shouldn't be writing code in the first place. (So maybe this is to spoonfeed the GNOME devs?)

        Comment


        • #5
          Originally posted by arQon View Post
          For a moment I thought this meant we might only be 10 or 15 years away from being able to remount an ejected USB device without physically replugging it, but then I realised this was just - well, actually, I STILL don't understand what the point of this is supposed to be. Yet another fsnotify-type layer, but just for devices?

          per milkylainen , anyone who can't already respond to the existing notifications competently probably shouldn't be writing code in the first place. (So maybe this is to spoonfeed the GNOME devs?)
          Maybe. I used the normal notifications to write my own identification layer for an embedded product 7-8 years ago.
          Disks (sdX, scsi layer), Cameras (videoX), Microphones (snd/X), Radiomodems (3G, Different devices, ACM, Option, etc.), Hotplugging various other devices.
          Worked a treat. Just think of it as something like miniature udev+actions.

          Comment


          • #6
            This is to determine when a something is mounted, not when a device is attached; a device may be remounted many times once attached . In particular, at a glance it also seems to report notifications for non-devices being mounted, such as a new tmpfs.

            ​​​​Maybe next time, bother to actually read the article fully before insulting the developers.

            Comment


            • #7
              Originally posted by arQon View Post
              For a moment I thought this meant we might only be 10 or 15 years away from being able to remount an ejected USB device without physically replugging it, but then I realised this was just - well, actually, I STILL don't understand what the point of this is supposed to be. Yet another fsnotify-type layer, but just for devices?

              per milkylainen , anyone who can't already respond to the existing notifications competently probably shouldn't be writing code in the first place. (So maybe this is to spoonfeed the GNOME devs?)
              You're assuming too much, really!

              fsnotify, inotify and whatever else notify only notify you of changes within a monitored path.
              They do not notify you of a mount change.
              And this is not a layer on top of those. It's a compliment to those, not a replacement or indirection.

              To make it more tangible. If you inject a USB stick (and assuming you had setup auto mounting), some process somewhere right now would poll /proc/mounts to let you know it has mounted. In this new system call you "get notified" by the kernel of that event hence dropping the requirement to do polling. It really is just a smarter way of doing things. The place that knows what happened (the kernel) can now tell the user "hey, i have a new mountpoint for you". Instead of the user repeatedly asking: "do you have a new mountpoint? now? now? now? now?..."

              Comment


              • #8
                Originally posted by markg85 View Post

                You're assuming too much, really!

                fsnotify, inotify and whatever else notify only notify you of changes within a monitored path.
                They do not notify you of a mount change.
                And this is not a layer on top of those. It's a compliment to those, not a replacement or indirection.

                To make it more tangible. If you inject a USB stick (and assuming you had setup auto mounting), some process somewhere right now would poll /proc/mounts to let you know it has mounted. In this new system call you "get notified" by the kernel of that event hence dropping the requirement to do polling. It really is just a smarter way of doing things. The place that knows what happened (the kernel) can now tell the user "hey, i have a new mountpoint for you". Instead of the user repeatedly asking: "do you have a new mountpoint? now? now? now? now?..."
                This can be done through inotify support over /proc/mounts or /proc/self/mountinfo.

                To be frank I really do not like such a tendency in Linux kernel development: let's add yet another system call for whatever new function.
                If such trend goes on, the linux system call will be more bloated than Win32 API in a few years.

                Comment


                • #9
                  Originally posted by markg85 View Post
                  You're assuming too much, really!
                  I'm not assuming anything. I have DONE this, as have most of the other posters in this thread.

                  Originally posted by markg85 View Post
                  To make it more tangible. If you inject a USB stick (and assuming you had setup auto mounting), some process somewhere right now would poll /proc/mounts to let you know it has mounted.
                  No it wouldn't. You're the only person suggesting that polling like that is somehow a sane way to do this. (Aside from Michael in the article, which I assume is from the RH justification rather than his personal opinion).

                  I'm not saying there's absolutely no valid use case for this - but I AM saying that I've yet to see what it is, and your suggestion isn't it. Though maybe one will come to someone at some point after coffee.

                  Comment


                  • #10
                    Originally posted by milkylainen View Post
                    The kernel has had block &- device notification for ages.
                    Can't see why a specific "mount notification" would be more valuable.
                    it's useful when you need to know when something has been mounted, duh.

                    Just knowing when a device appears or disappears does not tell much about its mount status. Plus the non-device stuff like bind mount and tmpfs.

                    Comment

                    Working...
                    X