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" <[email protected]>
Signed-off-by: Toshiyuki Okajima <[email protected]>
--
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(-)
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 */
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.
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.
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.
--
Dave Chinner
[email protected]
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.
On Thu, 14 Jan 2010 23:36:25 -0500
Andreas Dilger <[email protected]> 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
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.
--
Dave Chinner
[email protected]
On Fri, Jan 15, 2010 at 5:02 AM, Dave Chinner <[email protected]> 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
> [email protected]
> --
> 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 Fri, Jan 15, 2010 at 05:44:01AM -0600, Mike Mestnik wrote:
> On Fri, Jan 15, 2010 at 5:02 AM, Dave Chinner <[email protected]> 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.
--
Dave Chinner
[email protected]
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
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