From: Toshiyuki Okajima <[email protected]>
ext4 doesn't log a record of having unmounted the filesystem. And ext4 doesn't
log a record when the filesystem is remounted also with read-only. Therefore
in the system log, we cannot judge whether or not at the certain time this
filesystem user touches it.
For enterprise users, they often want to know when a certain filesystem is
mounted/remounted/unmounted.
So, we output the message to the system log when the filesystem is
remounted/unmounted.
Signed-off-by: Toshiyuki Okajima <[email protected]>
---
fs/ext4/super.c | 30 ++++++++++++++++++++++--------
1 file changed, 22 insertions(+), 8 deletions(-)
diff -Nurp linux-2.6.31.orig/fs/ext4/super.c linux-2.6.31/fs/ext4/super.c
--- linux-2.6.31.orig/fs/ext4/super.c 2009-09-10 07:13:59.000000000 +0900
+++ linux-2.6.31/fs/ext4/super.c 2009-09-11 17:11:07.000000000 +0900
@@ -508,6 +508,25 @@ void ext4_update_dynamic_rev(struct supe
*/
}
+static void ext4_print_mount_message(struct super_block *sb,
+ int is_remount)
+{
+ if (EXT4_SB(sb)->s_journal) {
+ ext4_msg(sb, KERN_INFO, "%s, %s journal on %s",
+ is_remount? "remounted": "mounted",
+ EXT4_SB(sb)->s_journal->j_inode ? "internal" :
+ "external", EXT4_SB(sb)->s_journal->j_devname);
+ } else {
+ ext4_msg(sb, KERN_INFO, "%s, no journal",
+ is_remount? "remounted": "mounted");
+ }
+}
+
+static void ext4_print_umount_message(struct super_block *sb)
+{
+ ext4_msg(sb, KERN_INFO, "unmounted");
+}
+
/*
* Open the external journal device
*/
@@ -645,6 +664,7 @@ static void ext4_put_super(struct super_
* Now that we are completely done shutting down the
* superblock, we need to actually destroy the kobject.
*/
+ ext4_print_umount_message(sb);
unlock_kernel();
unlock_super(sb);
kobject_put(&sbi->s_kobj);
@@ -1645,14 +1665,6 @@ static int ext4_setup_super(struct super
EXT4_BLOCKS_PER_GROUP(sb),
EXT4_INODES_PER_GROUP(sb),
sbi->s_mount_opt);
-
- if (EXT4_SB(sb)->s_journal) {
- ext4_msg(sb, KERN_INFO, "%s journal on %s",
- EXT4_SB(sb)->s_journal->j_inode ? "internal" :
- "external", EXT4_SB(sb)->s_journal->j_devname);
- } else {
- ext4_msg(sb, KERN_INFO, "no journal");
- }
return res;
}
@@ -2806,6 +2818,7 @@ no_journal:
}
ext4_setup_super(sb, es, sb->s_flags & MS_RDONLY);
+ ext4_print_mount_message(sb, 0);
/* determine the minimum size of new large inodes, if present */
if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE) {
@@ -3547,6 +3560,7 @@ static int ext4_remount(struct super_blo
old_opts.s_qf_names[i] != sbi->s_qf_names[i])
kfree(old_opts.s_qf_names[i]);
#endif
+ ext4_print_mount_message(sb, 1);
unlock_super(sb);
unlock_kernel();
return 0;
On Wed, Sep 30, 2009 at 03:49:31PM +0900, Toshiyuki Okajima wrote:
> From: Toshiyuki Okajima <[email protected]>
>
> ext4 doesn't log a record of having unmounted the filesystem. And ext4 doesn't
> log a record when the filesystem is remounted also with read-only. Therefore
> in the system log, we cannot judge whether or not at the certain time this
> filesystem user touches it.
> For enterprise users, they often want to know when a certain filesystem is
> mounted/remounted/unmounted.
>
> So, we output the message to the system log when the filesystem is
> remounted/unmounted.
>
> Signed-off-by: Toshiyuki Okajima <[email protected]>
The question of whether this should be at the VFS layer is still an
open one, I think. It is true that ext3 and ext4 does print some
filesystem specific information, but that could be handled via a new
method function in struct super_ops:
mount_msg(struct super *sb, char *buf, int buflen)
Note by the way that I've made some changes to clean up ext4's
mount/umount messages, trying to get rid of excess messages. In fact
ext4 already prints a "filesystem mounted" message in
ext4_fill_super(). You removed the one in ext4_setup_super(), but
I've already removed it in a recent commit pushed to Linus to remove
superflous mount-time printk's. I left the one at the very end of
ext4_fill_super() in; and your patch adds one about 2/3'rd of the way
into ext4_fill_super() --- so two "filesystem mounted" messages would
end up getting printed as a result.
Did you actually test the patch and see what sort of messages would be
printed as a result?
- Ted
Hi Ted, thank you for your comment.
Theodore Tso wrote:
> On Wed, Sep 30, 2009 at 03:49:31PM +0900, Toshiyuki Okajima wrote:
> > > From: Toshiyuki Okajima <[email protected]>
> > >
> > > ext4 doesn't log a record of having unmounted the filesystem. And ext4 doesn't
> > > log a record when the filesystem is remounted also with read-only. Therefore
> > > in the system log, we cannot judge whether or not at the certain time this
> > > filesystem user touches it.
> > > For enterprise users, they often want to know when a certain filesystem is
> > > mounted/remounted/unmounted.
> > >
> > > So, we output the message to the system log when the filesystem is
> > > remounted/unmounted.
> > >
> > > Signed-off-by: Toshiyuki Okajima <[email protected]>
>
> The question of whether this should be at the VFS layer is still an
> open one, I think. It is true that ext3 and ext4 does print some
I am recognizing it. But I think I have already explained its answer as follows:
- A print mechanism has already been included at mount time.
- The umount operation is opposite "mount operation". Therefore I think
it is no problem that we add the print mechanism at the umount time.
> filesystem specific information, but that could be handled via a new
> method function in struct super_ops:
>
> mount_msg(struct super *sb, char *buf, int buflen)
>
However, I have noticed that the purpose of ext3/ext4 messages at mount time
is for specific information but not for a general purpose by this comment.
So, I think I should rearrange this feature into the VFS layer.
I try to reimplement it later.
Thanks,
Toshiyuki Okajima
On Thu, Oct 01, 2009 at 12:20:17PM +0900, Toshiyuki Okajima wrote:
> I am recognizing it. But I think I have already explained its answer as follows:
> - A print mechanism has already been included at mount time.
It's true that some file systems already are printing a message at
mount time; but when we abstract up something to the VFS layer, that's
also an opportunity to remove some kernel printk's from some
filesystems, including ext2/3/4 at the same time this feature is
introduced.
> > filesystem specific information, but that could be handled via a new
> > method function in struct super_ops:
> >
> > mount_msg(struct super *sb, char *buf, int buflen)
> >
Note that what I was assuming is that we would is something like this
in the VFS mount code:
printk(KERN_INFO "Device %s mounted file system type %s read-%s%s\n",
sb->s_sid, sb->s_type->name,
sb->s_flags & MS_RDONLY ? "only" : "write",
sb->s_op->mount_msg ? sb->s_op->mount_msg(sb) : "");
The advantage of this is that we would now have a single consistent
kernel message for all file systems, with some room for file system
specific message.
- Ted
Hi Ted,
thank you for your comment.
Theodore Tso wrote:
> On Thu, Oct 01, 2009 at 12:20:17PM +0900, Toshiyuki Okajima wrote:
>> I am recognizing it. But I think I have already explained its answer as follows:
>> - A print mechanism has already been included at mount time.
>
> It's true that some file systems already are printing a message at
> mount time; but when we abstract up something to the VFS layer, that's
> also an opportunity to remove some kernel printk's from some
> filesystems, including ext2/3/4 at the same time this feature is
> introduced.
>
>>> filesystem specific information, but that could be handled via a new
>>> method function in struct super_ops:
>>>
>>> mount_msg(struct super *sb, char *buf, int buflen)
>>>
>
> Note that what I was assuming is that we would is something like this
> in the VFS mount code:
>
> printk(KERN_INFO "Device %s mounted file system type %s read-%s%s\n",
> sb->s_sid, sb->s_type->name,
> sb->s_flags & MS_RDONLY ? "only" : "write",
> sb->s_op->mount_msg ? sb->s_op->mount_msg(sb) : "");
>
> The advantage of this is that we would now have a single consistent
> kernel message for all file systems, with some room for file system
> specific message.
OK.
I try to implement the message mechanism at mount/umount time like
your description ASAP.
Best Regards,
Toshiyuki Okajima