public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Andreas Dilger <adilger@sun.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>,
	tytso@mit.edu, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org
Subject: Re: [REPOST][PATCH][RFC] vfs: add message print mechanism for the mount/umount into the VFS layer
Date: Fri, 15 Jan 2010 12:24:21 +1100	[thread overview]
Message-ID: <20100115012421.GA28498@discord.disaster> (raw)
In-Reply-To: <D69F3C0C-FC4A-4866-98BD-DE9558250A0B@sun.com>

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@fromorbit.com

  reply	other threads:[~2010-01-15  1:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-14  6:48 [REPOST][PATCH][RFC] vfs: add message print mechanism for the mount/umount into the VFS layer Toshiyuki Okajima
2010-01-14  8:14 ` Al Viro
2010-01-14 15:33   ` Andreas Dilger
2010-01-15  1:24     ` Dave Chinner [this message]
2010-01-15  4:36       ` Andreas Dilger
2010-01-15  8:31         ` Toshiyuki Okajima
2010-01-15 11:02         ` Dave Chinner
2010-01-15 11:44           ` Mike Mestnik
2010-01-15 13:15             ` Dave Chinner
2010-01-15 18:07       ` Valerie Aurora
2010-01-15 18:43         ` Ric Wheeler
  -- strict thread matches above, loose matches on Subject: below --
2009-11-04  4:49 [REPOST] [PATCH][RFC] " Toshiyuki Okajima

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100115012421.GA28498@discord.disaster \
    --to=david@fromorbit.com \
    --cc=adilger@sun.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=toshi.okajima@jp.fujitsu.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox