inotify/sysfs

[Quentin Glidic]

Hello,

In GIO (GLib), the GFileMonitor[1] mechanism is using inotify for local=
=20
files. To detect file creation and some other weird cases, they monitor=
=20
the directory of the file and not the file directly (see=20
get_basename/get_dirname[2] usage).

With sysfs, it does not work as expected for some reason.

From a quick discussion of IRC with GLib folks, it appears that it=20
would be better fixed in sysfs directly.

Would such a patch be accepted and if so, could I have some hints to=20
where I should start hacking to fix that?

Thanks,

[1] https://developer.gnome.org/gio/unstable/GFileMonitor.html
[2]=20
https://git.gnome.org/browse/glib/tree/gio/inotify/ginotifyfilemonitor.=
c#n82

--=20

Quentin =E2=80=9CSardem FF7=E2=80=9D Glidic
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel=
" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Jan Kara]

Hello,

Post by Quentin Glidic
In GIO (GLib), the GFileMonitor[1] mechanism is using inotify for
local files. To detect file creation and some other weird cases,
they monitor the directory of the file and not the file directly
(see get_basename/get_dirname[2] usage).
With sysfs, it does not work as expected for some reason.

Well, I'm rather surprised inotify works with sysfs at all ;) Why do you
need to watch sysfs? Udev is the tool with which you should generally look
for e.g. new devices... Anyway, if you'd like to add fsnotify() support
into sysfs, sysfs maintainer (Greg - added to CC) is the one to ask.

Honza

[Greg KH]

Post by Quentin Glidic
Hello,

Post by Quentin Glidic
In GIO (GLib), the GFileMonitor[1] mechanism is using inotify for
local files. To detect file creation and some other weird cases,
they monitor the directory of the file and not the file directly
(see get_basename/get_dirname[2] usage).
With sysfs, it does not work as expected for some reason.

Well, I'm rather surprised inotify works with sysfs at all ;) Why do you
need to watch sysfs? Udev is the tool with which you should generally look
for e.g. new devices... Anyway, if you'd like to add fsnotify() support
into sysfs, sysfs maintainer (Greg - added to CC) is the one to ask.

You forgot to cc: me :)

No, inotify doesn't work on sysfs, or if it does, that's by "accident",
and any data you are getting for this is probably totally wrong.

This is because the system would have to be constantly "opening" the
files to check for a value change in the kernel that represents the file
information. That would be hell on memory and overhead and just doesn't
make any sense at all.

For specific sysfs files that are ment to tell userspace that their
values changed, you can poll() on them, as they are set up to do this
properly.

If there are some specific sysfs files that you want to watch in this
manner, that don't support poll(), please let us know.

Also, if you are digging through sysfs files in the system, I'd
recommend using libudev, as that provides a much easier interface to
getting the data you need about the device you want.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Al Viro]

Post by Quentin Glidic
Hello,
In GIO (GLib), the GFileMonitor[1] mechanism is using inotify for
local files. To detect file creation and some other weird cases,
they monitor the directory of the file and not the file directly
(see get_basename/get_dirname[2] usage).
With sysfs, it does not work as expected for some reason.
From a quick discussion of IRC with GLib folks, it appears that it
would be better fixed in sysfs directly.

inotify does not and will not work on sysfs. Or procfs. Or devpts. Or
any number of network filesystems. No matter how hard somebody might wish
it to work, that's simply not feasible.

Linus, what do you think about flat-out refusing to create the watches on
filesystems that can't support them? At inotify_add_watch(2)/fanotify_mark(2)
time. Do you think that it would break syscall ABI warranties? As it is,
the caller has no way to tell it needs to go for a fallback, short of
getting ENOSYS on inotify_init(). And it *does* need to have fallback,
simply because there's no way in hell to get notifications for a lot of
places in synthetic filesystems, etc.

If userland developers pull that kind of stunts (see above re GLib crowd
trying to defend their garbage by suggesting that kernel must somehow
make *notify work on all filesystems), we'd better push back before that
behaviour spreads.

BTW, inotify(7) and inotify_add_watch(2) need to be fixed - they do not
mention these limitations at all. Assuming that reader has a clue and
realizes that there's no magic is not a good idea...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Linus Torvalds]

Post by Al Viro
Linus, what do you think about flat-out refusing to create the watches on
filesystems that can't support them?

Well, you seem to think that NFS and other network filesystems can't
support them.

But they can. It's just that they'll only trigger on *local* changes,
not on remote changes. But if you're doing a file manager on a
workstation, triggering on local changes is generally exactly what you
want.

But for /proc and /sys, I suspect you're right and we probably should
make it an error to not make people think they can do it. Or we should
specify some behavior (maybe it would be ok for certain subdirectories
for hotplug detection if we specify exactly when that is ok).

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Al Viro]

Post by Linus Torvalds

Post by Al Viro
Linus, what do you think about flat-out refusing to create the watches on
filesystems that can't support them?

Well, you seem to think that NFS and other network filesystems can't
support them.
But they can. It's just that they'll only trigger on *local* changes,
not on remote changes. But if you're doing a file manager on a
workstation, triggering on local changes is generally exactly what you
want.

... except when that workstation has e.g. /var/spool/mail NFS-mounted, with
MTA running on server. Or "wait until the job on server puts its results
into this file". And yes, I've seen requests along those lines ;-/
Cluster filesystems have the same issue...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Linus Torvalds]

Post by Al Viro
... except when that workstation has e.g. /var/spool/mail NFS-mounted, with
MTA running on server. Or "wait until the job on server puts its results
into this file". And yes, I've seen requests along those lines ;-/
Cluster filesystems have the same issue...

None of that matters.

A good file manager uses fsnotify to get efficient and timely local
notifications, and also does polling to check by hand - much less
timely, but covers the remote case.

The point is, fsnotify is very much a valid thing to do even on
networked filesystems, and even if you don't get full coverage.

The fact that people then *also* may use it incorrectly and think that
it is sufficient *without* the polling, that's not our problem. The
fact that stupid uses exist is not a reason to disable something that
_can_ be used intelligently.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html