On Fri, Jun 28, 2013 at 4:15 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jun 27, 2013 at 10:22:35PM +0800, Chinmay V S wrote: > >> [2] Also considering that inotify is *THE* "goto framework" for >> monitoring the filesystem, > > inotify is a mistake, with rather serious design restrictions on > possible uses. Don't step into it... *sigh* ok Al, i wish i had i had posted this query earlier, i really do. Inotify seemed a perfect solution for the system i had to design a. Single data "writer". b. Notification to all/any "reader" process on a write. c. Writer and reader process are not parent/child and no pre-determined order of execution. d. Events may NOT be dropped. And so far it works well for me too. Just that the kernel needs to be patched with support for IN_SYNC event in inotify that is triggered upon msync() upon a mmap-ed file. The only problem i have seen is that during stress testing the system (ARM Cortex A8 1Ghz, rootfs on NAND, kernel v2.6.37+inotify_patch) to ~100% cpu usage, and firing msync() events as fast as i can in the writer(>1000/s), consecutive events will get coalesced quite frequently before a reader is notified, i.e. one of the prior events is effectively dropped. The solution i have worked out for that as follows: 1. Mmap same file in both writer and reader maintain a circular buffer of data as a shared region. 2. Writer writes a record into the circular buffer and updates the "head" (a field in the shared region). 3. Writer performs an msync() 4. Readers receive an inotify event (running patched kernel with IN_SYNC support). 5. Readers check "head" in shared region and read all data from the last head value(tracked locally in the reader process) to the current head. 6. Update local head value to the value of the latest "head" in the shared region. While all this may sound a tad complicated, its all wrapped-up into 10KB of C code (and one kernel patch). Patch for reference: https://gist.github.com/TheCodeArtist/5874669 But i just could not sit in peace knowing that this inotify patch has NOT been accepted into the mainline, indicating some serious issues with this approach. I would really appreciate it if you(or anyone else for that matter) could please mention/elaborate *ANY* potential issues. thanks and regards ChinmayVS -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
