All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Beata Michalska <b.michalska@samsung.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, tytso@mit.edu,
	adilger.kernel@dilger.ca, hughd@google.com, lczerner@redhat.com,
	hch@infradead.org, linux-ext4@vger.kernel.org,
	linux-mm@kvack.org, kyungmin.park@samsung.com,
	kmpark@infradead.org,
	Linux Filesystem Mailing List <linux-fsdevel@vger.kernel.org>,
	linux-api@vger.kernel.org
Subject: Re: [RFC 1/4] fs: Add generic file system event notifications
Date: Fri, 17 Apr 2015 15:16:28 +0200	[thread overview]
Message-ID: <20150417131628.GA21539@quack.suse.cz> (raw)
In-Reply-To: <553104E5.2040704@samsung.com>

On Fri 17-04-15 15:04:37, Beata Michalska wrote:
> On 04/17/2015 01:31 PM, Jan Kara wrote:
> > On Wed 15-04-15 09:15:44, Beata Michalska wrote:
> > Also I think that we should make it clear that each event type has
> > different set of arguments. For threshold events they'll be L1 & L2, for
> > other events there may be no arguments, for other events maybe something
> > else...
> > 
> 
> Currently only the threshold events use arguments -  not sure what arguments
> could be used for the remaining notifications. But any suggestions are welcomed.
  Me neither be someone will surely find something in future ;)

> > ...
> >> +static const match_table_t fs_etypes = {
> >> +	{ FS_EVENT_INFO,    "info"  },
> >> +	{ FS_EVENT_WARN,    "warn"  },
> >> +	{ FS_EVENT_THRESH,  "thr"   },
> >> +	{ FS_EVENT_ERR,     "err"   },
> >> +	{ 0, NULL },
> >> +};
> >   Why are there these generic message types? Threshold messages make good
> > sense to me. But not so much the rest. If they don't have a clear meaning,
> > it will be a mess. So I also agree with a message like - "filesystem has
> > trouble, you should probably unmount and run fsck" - that's fine. But
> > generic "info" or "warning" doesn't really carry any meaning on its own and
> > thus seems pretty useless to me. To explain a bit more, AFAIU this
> > shouldn't be a generic logging interface where something like severity
> > makes sense but rather a relatively specific interface notifying about
> > events in filesystem userspace should know about so I expect relatively low
> > number of types of events, not tens or even hundreds...
> > 
> 
> Getting rid of those would simplify the configuration part, indeed.
> So we would be left with 'generic' and threshold events.
> I guess I've overdone this part.
  Well, I would avoid defining anything that's not really used. So
currently you can define threshold events and we start with just those.
When someone hooks up filesystem error paths to send notification, we can
create event type for telling "filesystem corrupted". And so on... We just
have to be careful to document that new event types can be added and
userspace has to ignore events it does not understand.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
To: Beata Michalska <b.michalska-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	tytso-3s7WtUTddSA@public.gmane.org,
	adilger.kernel-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org,
	hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
	lczerner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	kmpark-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	Linux Filesystem Mailing List
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC 1/4] fs: Add generic file system event notifications
Date: Fri, 17 Apr 2015 15:16:28 +0200	[thread overview]
Message-ID: <20150417131628.GA21539@quack.suse.cz> (raw)
In-Reply-To: <553104E5.2040704-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

On Fri 17-04-15 15:04:37, Beata Michalska wrote:
> On 04/17/2015 01:31 PM, Jan Kara wrote:
> > On Wed 15-04-15 09:15:44, Beata Michalska wrote:
> > Also I think that we should make it clear that each event type has
> > different set of arguments. For threshold events they'll be L1 & L2, for
> > other events there may be no arguments, for other events maybe something
> > else...
> > 
> 
> Currently only the threshold events use arguments -  not sure what arguments
> could be used for the remaining notifications. But any suggestions are welcomed.
  Me neither be someone will surely find something in future ;)

> > ...
> >> +static const match_table_t fs_etypes = {
> >> +	{ FS_EVENT_INFO,    "info"  },
> >> +	{ FS_EVENT_WARN,    "warn"  },
> >> +	{ FS_EVENT_THRESH,  "thr"   },
> >> +	{ FS_EVENT_ERR,     "err"   },
> >> +	{ 0, NULL },
> >> +};
> >   Why are there these generic message types? Threshold messages make good
> > sense to me. But not so much the rest. If they don't have a clear meaning,
> > it will be a mess. So I also agree with a message like - "filesystem has
> > trouble, you should probably unmount and run fsck" - that's fine. But
> > generic "info" or "warning" doesn't really carry any meaning on its own and
> > thus seems pretty useless to me. To explain a bit more, AFAIU this
> > shouldn't be a generic logging interface where something like severity
> > makes sense but rather a relatively specific interface notifying about
> > events in filesystem userspace should know about so I expect relatively low
> > number of types of events, not tens or even hundreds...
> > 
> 
> Getting rid of those would simplify the configuration part, indeed.
> So we would be left with 'generic' and threshold events.
> I guess I've overdone this part.
  Well, I would avoid defining anything that's not really used. So
currently you can define threshold events and we start with just those.
When someone hooks up filesystem error paths to send notification, we can
create event type for telling "filesystem corrupted". And so on... We just
have to be careful to document that new event types can be added and
userspace has to ignore events it does not understand.

								Honza
-- 
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Beata Michalska <b.michalska@samsung.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, tytso@mit.edu,
	adilger.kernel@dilger.ca, hughd@google.com, lczerner@redhat.com,
	hch@infradead.org, linux-ext4@vger.kernel.org,
	linux-mm@kvack.org, kyungmin.park@samsung.com,
	kmpark@infradead.org,
	Linux Filesystem Mailing List <linux-fsdevel@vger.kernel.org>,
	linux-api@vger.kernel.org
Subject: Re: [RFC 1/4] fs: Add generic file system event notifications
Date: Fri, 17 Apr 2015 15:16:28 +0200	[thread overview]
Message-ID: <20150417131628.GA21539@quack.suse.cz> (raw)
In-Reply-To: <553104E5.2040704@samsung.com>

On Fri 17-04-15 15:04:37, Beata Michalska wrote:
> On 04/17/2015 01:31 PM, Jan Kara wrote:
> > On Wed 15-04-15 09:15:44, Beata Michalska wrote:
> > Also I think that we should make it clear that each event type has
> > different set of arguments. For threshold events they'll be L1 & L2, for
> > other events there may be no arguments, for other events maybe something
> > else...
> > 
> 
> Currently only the threshold events use arguments -  not sure what arguments
> could be used for the remaining notifications. But any suggestions are welcomed.
  Me neither be someone will surely find something in future ;)

> > ...
> >> +static const match_table_t fs_etypes = {
> >> +	{ FS_EVENT_INFO,    "info"  },
> >> +	{ FS_EVENT_WARN,    "warn"  },
> >> +	{ FS_EVENT_THRESH,  "thr"   },
> >> +	{ FS_EVENT_ERR,     "err"   },
> >> +	{ 0, NULL },
> >> +};
> >   Why are there these generic message types? Threshold messages make good
> > sense to me. But not so much the rest. If they don't have a clear meaning,
> > it will be a mess. So I also agree with a message like - "filesystem has
> > trouble, you should probably unmount and run fsck" - that's fine. But
> > generic "info" or "warning" doesn't really carry any meaning on its own and
> > thus seems pretty useless to me. To explain a bit more, AFAIU this
> > shouldn't be a generic logging interface where something like severity
> > makes sense but rather a relatively specific interface notifying about
> > events in filesystem userspace should know about so I expect relatively low
> > number of types of events, not tens or even hundreds...
> > 
> 
> Getting rid of those would simplify the configuration part, indeed.
> So we would be left with 'generic' and threshold events.
> I guess I've overdone this part.
  Well, I would avoid defining anything that's not really used. So
currently you can define threshold events and we start with just those.
When someone hooks up filesystem error paths to send notification, we can
create event type for telling "filesystem corrupted". And so on... We just
have to be careful to document that new event types can be added and
userspace has to ignore events it does not understand.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2015-04-17 13:16 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15  7:15 [RFC 0/4] Generic file system events interface Beata Michalska
2015-04-15  7:15 ` Beata Michalska
2015-04-15  7:15 ` [RFC 1/4] fs: Add generic file system event notifications Beata Michalska
2015-04-15  7:15   ` Beata Michalska
2015-04-15 19:25   ` Darrick J. Wong
2015-04-15 19:25     ` Darrick J. Wong
2015-04-16  8:22     ` Beata Michalska
2015-04-16  8:22       ` Beata Michalska
2015-04-17  8:48       ` Jan Kara
2015-04-17  8:48         ` Jan Kara
2015-04-16  3:46   ` Eric Sandeen
2015-04-16  3:46     ` Eric Sandeen
2015-04-16  8:41     ` Beata Michalska
2015-04-16  8:41       ` Beata Michalska
2015-04-16 20:10       ` Hugh Dickins
2015-04-16 20:10         ` Hugh Dickins
2015-04-17  9:10         ` Beata Michalska
2015-04-17  9:10           ` Beata Michalska
2015-04-16 21:56   ` Heinrich Schuchardt
2015-04-16 21:56     ` Heinrich Schuchardt
2015-04-17  9:46     ` Beata Michalska
2015-04-17  9:46       ` Beata Michalska
2015-04-17  9:46       ` Beata Michalska
2015-04-17 11:58     ` Jan Kara
2015-04-17 11:58       ` Jan Kara
2015-04-17 11:31   ` Jan Kara
2015-04-17 11:31     ` Jan Kara
2015-04-17 13:04     ` Beata Michalska
2015-04-17 13:04       ` Beata Michalska
2015-04-17 13:15       ` Beata Michalska
2015-04-17 13:15         ` Beata Michalska
2015-04-17 13:16       ` Jan Kara [this message]
2015-04-17 13:16         ` Jan Kara
2015-04-17 13:16         ` Jan Kara
2015-04-17 13:23       ` Austin S Hemmelgarn
2015-04-17 13:41         ` Jan Kara
2015-04-17 13:41           ` Jan Kara
2015-04-17 14:51         ` John Spray
2015-04-17 14:51           ` John Spray
2015-04-17 15:43           ` Jan Kara
2015-04-17 15:43             ` Jan Kara
2015-04-17 16:08             ` John Spray
2015-04-17 16:08               ` John Spray
2015-04-17 16:08               ` John Spray
2015-04-17 16:22               ` Jan Kara
2015-04-17 16:22                 ` Jan Kara
2015-04-17 16:22                 ` Jan Kara
2015-04-17 16:29                 ` Austin S Hemmelgarn
2015-04-17 16:39                   ` Jan Kara
2015-04-17 16:39                     ` Jan Kara
2015-04-17 16:39                     ` Jan Kara
2015-04-17 17:37                 ` John Spray
2015-04-17 17:37                   ` John Spray
2015-04-17 22:37                   ` Andreas Dilger
2015-04-17 22:37                     ` Andreas Dilger
2015-04-17 16:25               ` Beata Michalska
2015-04-17 16:25                 ` Beata Michalska
2015-04-17 16:25                 ` Beata Michalska
2015-04-17 22:44     ` Andreas Dilger
2015-04-17 22:44       ` Andreas Dilger
2015-04-20  8:56       ` Beata Michalska
2015-04-20  8:56         ` Beata Michalska
2015-04-20 10:32       ` Jan Kara
2015-04-20 10:32         ` Jan Kara
2015-04-15  7:15 ` [RFC 2/4] ext4: Add helper function to mark group as corrupted Beata Michalska
2015-04-15  7:15   ` Beata Michalska
2015-04-15  7:15 ` [RFC 3/4] ext4: Add support for generic FS events Beata Michalska
2015-04-15  7:15   ` Beata Michalska
2015-04-15 19:18   ` Darrick J. Wong
2015-04-15 19:18     ` Darrick J. Wong
2015-04-16  8:02     ` Beata Michalska
2015-04-16  8:02       ` Beata Michalska
2015-04-15  7:15 ` [RFC 4/4] shmem: " Beata Michalska
2015-04-15  7:15   ` Beata Michalska
2015-04-17  8:17 ` [RFC 0/4] Generic file system events interface Jan Kara
2015-04-17  8:17   ` Jan Kara
2015-04-17  9:10   ` Beata Michalska
2015-04-17  9:10     ` Beata Michalska

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150417131628.GA21539@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger.kernel@dilger.ca \
    --cc=b.michalska@samsung.com \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=kmpark@infradead.org \
    --cc=kyungmin.park@samsung.com \
    --cc=lczerner@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.