linux-ext4 - Re: [REPOST][PATCH][RFC] vfs: add message print mechanism for the mount/umount into the VFS layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Jan 2010 23:36:25 -0500
From:	Andreas Dilger <adilger@....com>
To:	Dave Chinner <david@...morbit.com>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Toshiyuki Okajima <toshi.okajima@...fujitsu.com>,
	"Theodore Ts'o" <tytso@....edu>, linux-fsdevel@...r.kernel.org,
	"linux-ext4@...r.kernel.org development" <linux-ext4@...r.kernel.org>,
	"James C. Browne" <browne@...utexas.edu>
Subject: Re: [REPOST][PATCH][RFC] vfs: add message print mechanism for the
 mount/umount into the VFS layer

On 2010-01-14, at 20:24, Dave Chinner wrote:
> On Thu, Jan 14, 2010 at 10:33:42AM -0500, Andreas Dilger wrote:
>> 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....

I agree, of course, that /var/log/messages is an inefficient channel for
reporting status information from the kernel.

However, there are many reasons why it still makes sense to do this:
- it is in plain text format.  I can't recall the number of times
   people were proposing crazy schemes to have a text interface to the
   kernel (via /sys/blah, or /debugfs/blah) for things that are much
   better suited to an ioctl, since they are largely handled by binaries
   (applications), yet in the case where we have an existing plain-text
   interface (dmesg and /var/log/messages) that are meant (at least
   partly) for human consumption we are proposing a binary interface
- every system monitoring tool in existence has a /var/log/messages
   scraping interface, because this is the lowest common denominator,
   but I'd suspect that few/none have a netlink interface, or if they
   do it probably can't be easily added to by a user

If we are going to propose adding a binary interface for kernel status
notification, then we should discuss a proper interface for such that
is a real improvement over what we have today.  Things like having
proper error message numbers, error levels, subsystem identifiers,
timestamps, name=value status fields, not doing printf formatting in
the kernel, etc.

There are several major HPC sites that I know of that would LOVE to add
something like that, because they need to process the logs for thousands
of nodes in a cluster, and have people to work on it.  If there is  
interest
in the upstream kernel maintainers (i.e. Linus, Andrew) for reformatting
the printk() messages in the kernel to using a new binary interface  
(with
the option to format and dump them to the console for compatibility),
then great, I'm all for it.

However, it is doesn't make sense to me to suggest that people add  
random
binary status messages to netlink at random times without any kind of
planning or coordination, since it will just result in a mishmash of
ad-hoc messages, tools, etc, that will be far worse than what we have
today instead of improving what exists in /var/log/messages today.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html