On Thu, Jan 14, 2010 at 10:33:42AM -0500, Andreas Dilger wrote: > On 2010-01-14, at 03:14, Al Viro wrote: >> I am not going to apply that. For one thing, printk is improper >> mechanism >> for "observing [normal] operations". Vague references to "enterprise >> users" wanting that do not constitute a valid rationale. >> >> What's more, there is absolutely no point in taking care to have >> mount(2) >> spew something in log when explicitly asked to do so; caller can >> bloody >> well do it itself. From userland. > > Sure, it is _possible_ to do this, but you miss the fact that there are > many system monitoring tools that already scrape /var/log/messages and > integrate with event managers. What you are suggesting is that every > such tool implement an extra, completely ad-hoc mechanism just for > monitoring the mount/unmount of filesystems on Linux. That doesn't make > sense. We already report various events through a netlink interface, but not to the log files (e.g. quota warnings), so those system monitoring tools are already going to be missing interesting information. Using log files for system event notification used to be the only way to communicate such events. Now we have much more advanced and efficient mechanisms for notifications so I think we should use them. FWIW, having a general event channel for reporting filesystem events like mount, enospc, corruption, etc makes a lot of sense to me. Especially from the point of view that they can be also be tied into automated filesystem test harnesses easily.... > Conversely, adding a new monitor for a message in /var/log/messages is > simply a matter of adding a scanf() format string to their existing list > of format strings - a 5-minute exercise for a junior sysadmin. Writing a netlink interface for listening to events is not that much harder, either.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
