From: Al Viro <viro@ZenIV.linux.org.uk>
To: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Cc: 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: Thu, 14 Jan 2010 08:14:48 +0000 [thread overview]
Message-ID: <20100114081448.GI19799@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20100114154837.734fff60.toshi.okajima@jp.fujitsu.com>
On Thu, Jan 14, 2010 at 03:48:37PM +0900, Toshiyuki Okajima wrote:
> Hi.
>
> Now, on the VFS-layer any messages aren't printed at mount/umount time
> (when the operation normally terminates).
> But there are some filesystems which print their own specific messages at those
> times.
>
> For the purpose of the system management and so on, users (especially,
> enterprise users) want to observe their system operations from the system logs.
> We may manage to observe some filesystems' operations (mount/umount) from the
> logs. But the filesystems of which we can observe the operations are not all.
>
> Therefore to achieve the observations for all filesystems is to add the common
> message mechanism into the VFS layer. If any filesystems' specific messages at
> mount/umount time are added into this, we can distinguish more easily each
> message among the system logs for our systems' observations.
>
> This patch provides the following:
> - message output of common format from VFS at mount/umount time
> - the functions of printing the filesystem's specific information at
> mount/umount time
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. And on umount side your logics is
simply b0rken, since the presence of report depends on the order of vfsmount
demise in case when there are several vfsmounts over given superblock.
I can see a value in having something e.g. in /proc that would report the
list of active filesystems (or active filesystems of given type). poll()able,
a-la /proc/mounts. Format of such thing would have to be considered
carefully, but at least it's something that might make sense.
next prev parent reply other threads:[~2010-01-14 8:14 UTC|newest]
Thread overview: 13+ 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 [this message]
2010-01-14 9:03 ` Mike Mestnik
2010-01-14 15:33 ` Andreas Dilger
2010-01-15 1:24 ` Dave Chinner
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=20100114081448.GI19799@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=toshi.okajima@jp.fujitsu.com \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).