| Message ID | 20100114154837.734fff60.toshi.okajima@jp.fujitsu.com |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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.
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
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
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.
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
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.
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
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
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 */
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