Patchwork [REPOST,RFC] vfs: add message print mechanism for the mount/umount into the VFS layer

login
register
mail settings
Submitter Toshiyuki Okajima
Date Jan. 14, 2010, 6:48 a.m.
Message ID <20100114154837.734fff60.toshi.okajima@jp.fujitsu.com>
Download mbox | patch
Permalink /patch/42849/
State New
Headers show

Comments

Toshiyuki Okajima - Jan. 14, 2010, 6:48 a.m.
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

(NOTE: This mechanism becomes effective only when the users call
       the mount system call because they don't want to observe the pseudo 
       filesystems.)

Example of display:
--------------------------------------------------------------------------------
Device sda1 mounted file system type ext3 read-write
Device sda2 mounted file system type ext3 read-write
Device sdd2 mounted file system type ext3 read-write
Device sdd2 unmounted
--------------------------------------------------------------------------------

P.S.
This concept derives from the following:
- http://marc.info/?l=linux-ext4&m=125429349122986&w=2
- http://marc.info/?l=linux-ext4&m=125436936109125&w=2 

Cc: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
--
 fs/namespace.c        |   19 ++++++++++++++++++-
 fs/super.c            |   18 ++++++++++++++++--
 include/linux/fs.h    |    3 +++
 include/linux/mount.h |    3 +++
 4 files changed, 40 insertions(+), 3 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Al Viro - Jan. 14, 2010, 8:14 a.m.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andreas Dilger - Jan. 14, 2010, 3:33 p.m.
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.

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.

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dave Chinner - Jan. 15, 2010, 1:24 a.m.
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.
Andreas Dilger - Jan. 15, 2010, 4:36 a.m.
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Toshiyuki Okajima - Jan. 15, 2010, 8:31 a.m.
On Thu, 14 Jan 2010 23:36:25 -0500
Andreas Dilger <adilger@sun.com> wrote:

> 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.

My true purpose is to confirm time when a certain ext3 filesystem
was unmounted.
(We can confirm time when a certain ext3 filesystem was mounted because
ext3 filesystem prints the specific messages at mount. Therefore, to add "unmount"
message into ext3 satisfies my purpose. But to add the one into VFS layer is more
appropriate because we can distinguish the events (mount/unmount) for other
filesystems.)
-------------------------------------------------------------------------------------
Background:
I am an investigator of the root causes of my user incidents. When I investigated
a user's incident, I wanted to know whether a certain mounted ext3 filesystem
had been clearly unmounted or not. Because a certain problem could not occur if its
filesystem had been already unmounted. But now, there is no way to know whether
filesystems were unmounted after the event was done.
Owing to this reason, I want some mechanisms to know whether a certain filesystem
is clearly unmounted after such events was done.
Therefore, I proposed the additional print mechanism in VFS layer.
-------------------------------------------------------------------------------------
For such a purpose, I think the text message in /var/log/messages is more appropriate.

Regards,
Toshiyuki Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dave Chinner - Jan. 15, 2010, 11:02 a.m.
On Thu, Jan 14, 2010 at 11:36:25PM -0500, Andreas Dilger wrote:
> 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.
....
> 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

A daemon that captures the events from netlink and writes them to
syslog is all that is needed to support log file scraping
monitoring tools. The message they scrape does not have to come from
the kernel...

> 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.

Event notifications don't need this sort of complexity - classifying
an event is something for the userspace side of the notification -
it is the policy part of the equation.  Different applications will
do this differently. e.g. system monitoring might write it to syslog
for the scraper to read, while a desktop subsystem might deliver it
to a taskbar notification mechanism to generate a usre visible popup
message.

IMO, using printk() for such notifications provides none of the
flexibility that modern systems require, but events can easily be
used to support legacy methods of event reporting. Hence it seems to
me like a no brainer to use events rather than printk for all new
notifications....

Cheers,

Dave.
Mike Mestnik - Jan. 15, 2010, 11:44 a.m.
On Fri, Jan 15, 2010 at 5:02 AM, Dave Chinner <david@fromorbit.com> wrote:
> On Thu, Jan 14, 2010 at 11:36:25PM -0500, Andreas Dilger wrote:
>> 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.
> ....
>> 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
>
> A daemon that captures the events from netlink and writes them to
> syslog is all that is needed to support log file scraping
> monitoring tools. The message they scrape does not have to come from
> the kernel...
>
klogd.  Do we need another wheel?

Moving this to userland as suggested seams like it would create more
problems then it would solve.

>> 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.
>
> Event notifications don't need this sort of complexity - classifying
> an event is something for the userspace side of the notification -
> it is the policy part of the equation.  Different applications will
> do this differently. e.g. system monitoring might write it to syslog
> for the scraper to read, while a desktop subsystem might deliver it
> to a taskbar notification mechanism to generate a usre visible popup
> message.
>
> IMO, using printk() for such notifications provides none of the
> flexibility that modern systems require, but events can easily be
> used to support legacy methods of event reporting. Hence it seems to
> me like a no brainer to use events rather than printk for all new
> notifications....
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dave Chinner - Jan. 15, 2010, 1:15 p.m.
On Fri, Jan 15, 2010 at 05:44:01AM -0600, Mike Mestnik wrote:
> On Fri, Jan 15, 2010 at 5:02 AM, Dave Chinner <david@fromorbit.com> wrote:
> > On Thu, Jan 14, 2010 at 11:36:25PM -0500, Andreas Dilger wrote:
> >> 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.
> > ....
> >> 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
> >
> > A daemon that captures the events from netlink and writes them to
> > syslog is all that is needed to support log file scraping
> > monitoring tools. The message they scrape does not have to come from
> > the kernel...
> >
> klogd.  Do we need another wheel?

That's just another syslog implementation for directing printk
messages to files. It's not an event notification framework.

Cheers,

Dave.
Valerie Aurora Henson - Jan. 15, 2010, 6:07 p.m.
On Fri, Jan 15, 2010 at 12:24:21PM +1100, Dave Chinner wrote:
> 
> 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....

Mmm, yummy!  Is this perhaps a topic for the next file systems workshop?

(When _is_ the next file systems workshop?)

-VAL
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ric Wheeler - Jan. 15, 2010, 6:43 p.m.
On 01/15/2010 01:07 PM, Valerie Aurora wrote:
> On Fri, Jan 15, 2010 at 12:24:21PM +1100, Dave Chinner wrote:
>    
>> 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....
>>      
> Mmm, yummy!  Is this perhaps a topic for the next file systems workshop?
>
> (When _is_ the next file systems workshop?)
>
> -VAL
>    

I think that the current plan is to have it next to the LinuxCon event 
in Boston in early August....

The VM people are looking to do a mini-summit there as well and we were 
talking about getting together with them during part of the time,

Ric

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

Patch

diff -Nurp linux-2.6.33-rc3.org/fs/namespace.c linux-2.6.33-rc3/fs/namespace.c
--- linux-2.6.33-rc3.org/fs/namespace.c	2010-01-06 09:02:46.000000000 +0900
+++ linux-2.6.33-rc3/fs/namespace.c	2010-01-12 16:41:00.000000000 +0900
@@ -599,6 +599,7 @@  static struct vfsmount *clone_mnt(struct
 static inline void __mntput(struct vfsmount *mnt)
 {
 	struct super_block *sb = mnt->mnt_sb;
+	int silent = !(mnt->mnt_flags & MNT_VERBOSE_MSG);
 	/*
 	 * This probably indicates that somebody messed
 	 * up a mnt_want/drop_write() pair.  If this
@@ -612,7 +613,7 @@  static inline void __mntput(struct vfsmo
 	WARN_ON(count_mnt_writers(mnt));
 	dput(mnt->mnt_root);
 	free_vfsmnt(mnt);
-	deactivate_super(sb);
+	__deactivate_super(sb, silent);
 }
 
 void mntput_no_expire(struct vfsmount *mnt)
@@ -1653,6 +1654,9 @@  static int do_new_mount(struct path *pat
 	if (IS_ERR(mnt))
 		return PTR_ERR(mnt);
 
+	/* for verbose messages on VFS layer at mount/umount */
+	if (!(flags & MS_SILENT))
+		mnt_flags |= MNT_VERBOSE_MSG;
 	return do_add_mount(mnt, path, mnt_flags, NULL);
 }
 
@@ -1664,6 +1668,7 @@  int do_add_mount(struct vfsmount *newmnt
 		 int mnt_flags, struct list_head *fslist)
 {
 	int err;
+	struct super_block *sb = newmnt->mnt_sb;
 
 	down_write(&namespace_sem);
 	/* Something was mounted here while we slept */
@@ -1692,10 +1697,22 @@  int do_add_mount(struct vfsmount *newmnt
 		list_add_tail(&newmnt->mnt_expire, fslist);
 
 	up_write(&namespace_sem);
+	/* 
+	 * message output at mount for log observers
+	 */
+	if (newmnt->mnt_flags & MNT_VERBOSE_MSG) {
+		printk(KERN_INFO "Device %s mounted file system type %s read-%s\n",
+					sb->s_id, sb->s_type->name,
+					sb->s_flags & MS_RDONLY ? "only" : "write");
+		/* fs specific messages for mount */
+		if (sb->s_op != NULL && sb->s_op->mount_msg != NULL)
+			sb->s_op->mount_msg(sb);
+	}
 	return 0;
 
 unlock:
 	up_write(&namespace_sem);
+	newmnt->mnt_flags &= ~MNT_VERBOSE_MSG;
 	mntput(newmnt);
 	return err;
 }
diff -Nurp linux-2.6.33-rc3.org/fs/super.c linux-2.6.33-rc3/fs/super.c
--- linux-2.6.33-rc3.org/fs/super.c	2010-01-06 09:02:46.000000000 +0900
+++ linux-2.6.33-rc3/fs/super.c	2010-01-12 16:41:00.000000000 +0900
@@ -177,15 +177,16 @@  void put_super(struct super_block *sb)
 
 
 /**
- *	deactivate_super	-	drop an active reference to superblock
+ *	__deactivate_super	-	drop an active reference to superblock
  *	@s: superblock to deactivate
+ *	@silent: disable verbose messages for umount from mount-tree
  *
  *	Drops an active reference to superblock, acquiring a temprory one if
  *	there is no active references left.  In that case we lock superblock,
  *	tell fs driver to shut it down and drop the temporary reference we
  *	had just acquired.
  */
-void deactivate_super(struct super_block *s)
+void __deactivate_super(struct super_block *s, int silent)
 {
 	struct file_system_type *fs = s->s_type;
 	if (atomic_dec_and_lock(&s->s_active, &sb_lock)) {
@@ -193,12 +194,25 @@  void deactivate_super(struct super_block
 		spin_unlock(&sb_lock);
 		vfs_dq_off(s, 0);
 		down_write(&s->s_umount);
+		/* fs specific messages for umount */
+		if (!silent && s->s_op != NULL && s->s_op->umount_msg != NULL)
+			s->s_op->umount_msg(s);
 		fs->kill_sb(s);
+		/*
+		 * message output at umount for log observers
+		 */ 
+		if (!silent)
+			printk(KERN_INFO "Device %s unmounted\n", s->s_id);
 		put_filesystem(fs);
 		put_super(s);
 	}
 }
 
+void deactivate_super(struct super_block *s)
+{
+	__deactivate_super(s, !0);
+}
+
 EXPORT_SYMBOL(deactivate_super);
 
 /**
diff -Nurp linux-2.6.33-rc3.org/include/linux/fs.h linux-2.6.33-rc3/include/linux/fs.h
--- linux-2.6.33-rc3.org/include/linux/fs.h	2010-01-06 09:02:46.000000000 +0900
+++ linux-2.6.33-rc3/include/linux/fs.h	2010-01-12 16:41:00.000000000 +0900
@@ -1575,6 +1575,8 @@  struct super_operations {
 	ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
 #endif
 	int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t);
+	void (*mount_msg)(struct super_block*);
+	void (*umount_msg)(struct super_block*);
 };
 
 /*
@@ -1766,6 +1768,7 @@  void kill_block_super(struct super_block
 void kill_anon_super(struct super_block *sb);
 void kill_litter_super(struct super_block *sb);
 void deactivate_super(struct super_block *sb);
+void __deactivate_super(struct super_block *sb, int silent);
 void deactivate_locked_super(struct super_block *sb);
 int set_anon_super(struct super_block *s, void *data);
 struct super_block *sget(struct file_system_type *type,
diff -Nurp linux-2.6.33-rc3.org/include/linux/mount.h linux-2.6.33-rc3/include/linux/mount.h
--- linux-2.6.33-rc3.org/include/linux/mount.h	2010-01-06 09:02:46.000000000 +0900
+++ linux-2.6.33-rc3/include/linux/mount.h	2010-01-12 16:41:00.000000000 +0900
@@ -36,6 +36,9 @@  struct mnt_namespace;
 #define MNT_UNBINDABLE	0x2000	/* if the vfsmount is a unbindable mount */
 #define MNT_PNODE_MASK	0x3000	/* propagation flag mask */
 
+#define MNT_VERBOSE_MSG	0x10000 /* verbose messages on the VFS layer at mount
+				   /umount only when called from do_new_mount */
+
 struct vfsmount {
 	struct list_head mnt_hash;
 	struct vfsmount *mnt_parent;	/* fs we are mounted on */