0

Can I get the information stored in /proc via system calls instead of processing text from files?

I am trying to list inotify watches which are preventing the unmount of a filesystem.

Ive written part of a shell script, but it's already too slow. I'm thinking of rewriting in Perl.

Is there a way to get the /proc information from system calls for a further speed up?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Tom Hale
  • 40,825
  • 36
  • 187
  • 242
  • 1
    I believe the whole point of the `/proc` pseudo-filesystem is to aggregate under one simple structure what would be many different system calls or direct access to protected kernel memory. – Jim Garrison Aug 30 '17 at 04:31
  • Inotify watches *can not* prevent unmounting of filesystem. The documentation even mentions the specialized inotify event, that gets dispatched when the filesystem is unmounted: "IN_UNMOUNT - Filesystem containing watched object was unmounted". And if you were to read a tiny bit on the subject, you would discover, that inotify/fanotify have been specifically created to address issue of their predecessor dnotify, which didn't support unmounting watched directory. – user1643723 Aug 30 '17 at 11:43
  • Incorrect, they [can indeed](https://sort.symantec.com/public/documents/sfha/5.1sp1/linux/productguides/html/sf_notes/ch01s09s04s12.htm). – Tom Hale Sep 01 '17 at 03:04
  • @TomHale No, they can not. The passage, cited in my comment, comes from the [Linux manpage of inotify](http://man7.org/linux/man-pages/man7/inotify.7.html), and it explicitly says, that partitions with inotify-watched objects can be unmounted. You have linked to Symantec article, which mentions a known issue of Veritas File System (a proprietary HP UX file system, ported to Linux a while ago). That article acknowledges the issue as a bug, and notes lack of workaround. AFAIK, none of filesystems, officially supported by upstream Linux, exhibit such issues. – user1643723 Sep 01 '17 at 21:55
  • I have experienced it on `btrfs`, the transcript showing it happening is shown [here](https://unix.stackexchange.com/q/386877/143394). – Tom Hale Sep 02 '17 at 04:14
  • @TomHale "the transcript showing it" — the transcript hardly shows anything. At most, it can be taken to mean, that: 1. syncthing is preventing unmounting of the directory 2. `lsof` fails to identify the source of issue. Why do you assume, that this has something to do with inotify, rather than, for example, some brtfs-specific bug in `lsof`? What are contents of syncthing's `/proc/xxx/fd/` when `unmount` fails? – user1643723 Sep 02 '17 at 06:58

1 Answers1

2

No, there is no other interface to /proc nodes besides the open() and read() system calls.

Keep in mind that nodes under /proc aren't real files. Reads from them will return as quickly as the content can be generated by the kernel -- an alternate interface wouldn't be any faster.

That all being said, reimplementing your shell script in any programming language that can read files directly (like Perl) will already speed it up dramatically. In a shell script, you're launching a new process, or possibly even multiple processes, every time you call ls or grep. Launching processes is relatively slow -- getting away from that will probably solve your speed problems.

  • *"an alternate interface wouldn't be any faster"* - the difference is that "files" in proc are text streams, so kernel has to write data in textual format and then application has to parse it back, whereas alternative interface could provide "raw" data. – el.pescado - нет войне Aug 30 '17 at 05:48
  • 1
    @el.pescado: Converting single integer to a string and back is rarely a bottleneck. Opening a file is much more consuming (at least, because it is a *syscall*, not a pure user-space function). But, as @duskwuff said, there is no other interface to `/proc`. – Tsyvarev Aug 30 '17 at 07:41