So, I need to monitor a fairly large nested directory tree for changes on Linux. It seems like there are a few different watcher modules that I could use – fsnotify and notify being the main ones, both of which use the inotify interface and attempt to set watches on each individual subdirectory and maintain all their watchers as things change. I have way too many directories for that to be a workable approach. It looks like the underlying issue is just that this is a difficult problem on Linux; both inotify and fanotify have some issues which make them difficult for library authors to use to present a clean and useful API.
Long story short - I coded up an fanotify-based solution which seems like a good start of what I need, and I’m planning on sharing it back in the hopes that it’s useful. I guess my question is, did I miss something? Is there already an easy and straightforward way to monitor a big directory for changes?
You must log in or register to comment.
Just the other day I wrote something just like this, but I used inotify.
I have to monitor a fairly small direcotry tho, so I didn’t encounter any problem.
both of which use the inotify interface and attempt to set watches on each individual subdirectory
Is this really necessary? Inotify’s man page says it can monitor a whole directory with only one watch, so that’s what I did and it looks like it’s working
I didn’t make a lot of tests tho, so I might be wrong
Edit: from the inotify man page:
Inotify monitoring of directories is not recursive: to monitor subdirectories under a directory, additional watches must be created. This can take a significant amount time for large directory trees.
Yeah, it is necessary. That’s what I get for not reading the whole thing.
have you tried https://github.com/watchexec/watchexec
Just looking briefly it looks like it uses inotify (which definitely won’t work; I don’t have a super heavy write load but I have a total of 124,000 subdirectories to monitor) or can fall back to polling (which I could do myself without having to involve a library).
Why this app is constructed to store its stuff in 124,000 subdirectories is a separate issue but one that I can’t immediately snap my fingers and make go away, unfortunately.
124,000 subdirectories is a separate issue
Yeah sure, but that’s also not for discussion here.
Would it solve the issue by finding the limit of how much inotify can handle and then running multiple instances of a watcher on a subset of directories?
Say, inotify can deal with 1000 subdirs, so having 124 instances running should in theory be equal in resourse usage as if it would monitor 124k subdirs, give or take.
Just a thought tho 🤷♂️
Just chiming in to say I was unaware of how limiting inotify is because of the relatively trivial cases in which I’ve used it. I’d be interested to see the alternative you’ve come up with!
