Hi Ted, Andrew and all.
Under the current implementation, we cannot know in the system log
(/var/log/messages) when the filesystem (ext2/ext3/ext4) is unmounted.
For enterprise users, they often want to observe certain filesystems'
actions (mount/unmount) in the system log. Besides, by the system log,
we occasionally wants to know whether a certain filesystem has been
unmounted or not at the time when a problem happens.
The following patch series implement above demand.
Please apply it.
Signed-off-by: Toshiyuki Okajima <[email protected]>
---
fs/ext2/super.c | 16 ++++++++++++++++
fs/ext3/super.c | 32 +++++++++++++++++++++++---------
fs/ext4/super.c | 30 ++++++++++++++++++++++--------
3 files changed, 61 insertions(+), 17 deletions(-)
Regards,
Toshiyuki Okajima
Toshiyuki Okajima wrote:
> Hi Ted, Andrew and all.
>
> Under the current implementation, we cannot know in the system log
> (/var/log/messages) when the filesystem (ext2/ext3/ext4) is unmounted.
> For enterprise users, they often want to observe certain filesystems'
> actions (mount/unmount) in the system log. Besides, by the system log,
> we occasionally wants to know whether a certain filesystem has been
> unmounted or not at the time when a problem happens.
>
> The following patch series implement above demand.
> Please apply it.
If this is really a common requirement, perhaps we should at least
consider putting it in the vfs, in vfs_kern_mount(),
generic_shutdown_super(), and do_remount_sb().
That way we'll have common behavior and less replicated code; nothing in
this patch series is unique to ext[234] as far as I can tell.
sb->s_type->name could be used to print the fs type in a generic message.
-Eric
> Signed-off-by: Toshiyuki Okajima <[email protected]>
> ---
> fs/ext2/super.c | 16 ++++++++++++++++
> fs/ext3/super.c | 32 +++++++++++++++++++++++---------
> fs/ext4/super.c | 30 ++++++++++++++++++++++--------
> 3 files changed, 61 insertions(+), 17 deletions(-)
>
> Regards,
> Toshiyuki Okajima
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 15 Sep 2009 15:20:39 +0900
Toshiyuki Okajima <[email protected]> wrote:
> Hi Ted, Andrew and all.
>
> Under the current implementation, we cannot know in the system log
> (/var/log/messages) when the filesystem (ext2/ext3/ext4) is unmounted.
> For enterprise users, they often want to observe certain filesystems'
> actions (mount/unmount) in the system log. Besides, by the system log,
> we occasionally wants to know whether a certain filesystem has been
> unmounted or not at the time when a problem happens.
>
I don't think we want to make random printks a part of the kernel
ABI like this.
I understand that it's practical and easy for people to parse the logs
in a local ad-hoc manner such as this, but... ugh.
If there's a userspace requirement for notification when filesystems
are mounted and unmounted then fine, let's look at that. What is the
detailed requirement? What info do we want to see? What is an
appropriate way of delivering that info? kobject_uevent() looks like a
suitable place to start.
That being said, there is perhaps a case to made for being more verbose
when filesystems are mounted and unmounted. But yes, doing that in the
VFS for all filesystems sounds better. This might upset people who
have thousands of NFS autmounts though.
Hi Eric,
Thanks for your comment.
On Tue, 15 Sep 2009 10:15:58 -0500
Eric Sandeen <[email protected]> wrote:
> Toshiyuki Okajima wrote:
> > Hi Ted, Andrew and all.
> >
> > Under the current implementation, we cannot know in the system log
> > (/var/log/messages) when the filesystem (ext2/ext3/ext4) is unmounted.
> > For enterprise users, they often want to observe certain filesystems'
> > actions (mount/unmount) in the system log. Besides, by the system log,
> > we occasionally wants to know whether a certain filesystem has been
> > unmounted or not at the time when a problem happens.
> >
> > The following patch series implement above demand.
> > Please apply it.
>
> If this is really a common requirement, perhaps we should at least
> consider putting it in the vfs, in vfs_kern_mount(),
> generic_shutdown_super(), and do_remount_sb().
Yes. I also thought it was appropriate that where this feature was implemented
was on VFS. But ext3/ext4 has already included the message mechanism which
operates when ext3/ext4 is mounted/remounted.
So, to achieve this feature easily, I have rearranged the message mechanism in
ext3/ext4 (ext2 is newly implemented).
>
> That way we'll have common behavior and less replicated code; nothing in
> this patch series is unique to ext[234] as far as I can tell.
>
> sb->s_type->name could be used to print the fs type in a generic message.
Thanks,
Toshiyuki Okajima
Hi Andrew,
Thanks for your comment.
On Tue, 15 Sep 2009 15:20:44 -0700
Andrew Morton <[email protected]> wrote:
> On Tue, 15 Sep 2009 15:20:39 +0900
> Toshiyuki Okajima <[email protected]> wrote:
>
> > Hi Ted, Andrew and all.
> >
> > Under the current implementation, we cannot know in the system log
> > (/var/log/messages) when the filesystem (ext2/ext3/ext4) is unmounted.
> > For enterprise users, they often want to observe certain filesystems'
> > actions (mount/unmount) in the system log. Besides, by the system log,
> > we occasionally wants to know whether a certain filesystem has been
> > unmounted or not at the time when a problem happens.
> >
>
> I don't think we want to make random printks a part of the kernel
> ABI like this.
Yes.
However, the message of the mount is already included in ext3/ext4.
So, I think it is no problem that the message of the umount which is opposite
operation of the mount is added. And it is natural, I think.
>
> I understand that it's practical and easy for people to parse the logs
> in a local ad-hoc manner such as this, but... ugh.
>
> If there's a userspace requirement for notification when filesystems
> are mounted and unmounted then fine, let's look at that. What is the
> detailed requirement? What info do we want to see? What is an
> appropriate way of delivering that info? kobject_uevent() looks like a
> suitable place to start.
>
>
> That being said, there is perhaps a case to made for being more verbose
> when filesystems are mounted and unmounted. But yes, doing that in the
> VFS for all filesystems sounds better. This might upset people who
> have thousands of NFS autmounts though.
Sample case (this feature is required):
A filesystem detects its corruption. A user asks me why the filesystem
has been corrupted. The user send me a material to examine why it happens.
The material is the system log. He cannot send me any other materials.
Because his machine does mission critical jobs, so he doesn't want to stop
it. Therefore only by the system log I have to examine why it happens.
Whenever I solve such a problem, I want the time stamp which is made
when the filesystem is mounted/unmounted.
If this feature is included, I can easily understand whether the filesystem
is mounted or not in a certain time zone by checking the time stamps.
For example:
If he restored the filesystem at a certain time, I can judge whether
he left the filesystem mounted or not by this feature.
(If he left the filesystem mounted, the filesystem was corrupted by his
restoration operation.)
Thanks,
Toshiyuki Okajima