All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Beata Michalska <b.michalska@samsung.com>,
	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:41:44 +0200	[thread overview]
Message-ID: <20150417134144.GA23905@quack.suse.cz> (raw)
In-Reply-To: <55310957.3070101@gmail.com>

On Fri 17-04-15 09:23:35, Austin S Hemmelgarn wrote:
> On 2015-04-17 09:04, Beata Michalska wrote:
> >On 04/17/2015 01:31 PM, Jan Kara wrote:
> >>On Wed 15-04-15 09:15:44, Beata Michalska wrote:
> >>...
> >>>+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...
> >>
> >>								Honza
> >
> >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.
> 
> For some filesystems, it may make sense to differentiate between a
> generic warning and an error.  For BTRFS and ZFS for example, if
> there is a csum error on a block, this will get automatically
> corrected in many configurations, and won't require anything like
> fsck to be run, but monitoring applications will still probably want
> to be notified.
   Sure, but in that case just create an event CORRECTED_CHECKSUM_ERROR and
use that. Then userspace knows what it should do with the event. No need to
hide it behind warning / error category.

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

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Beata Michalska <b.michalska@samsung.com>,
	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:41:44 +0200	[thread overview]
Message-ID: <20150417134144.GA23905@quack.suse.cz> (raw)
In-Reply-To: <55310957.3070101@gmail.com>

On Fri 17-04-15 09:23:35, Austin S Hemmelgarn wrote:
> On 2015-04-17 09:04, Beata Michalska wrote:
> >On 04/17/2015 01:31 PM, Jan Kara wrote:
> >>On Wed 15-04-15 09:15:44, Beata Michalska wrote:
> >>...
> >>>+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...
> >>
> >>								Honza
> >
> >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.
> 
> For some filesystems, it may make sense to differentiate between a
> generic warning and an error.  For BTRFS and ZFS for example, if
> there is a csum error on a block, this will get automatically
> corrected in many configurations, and won't require anything like
> fsck to be run, but monitoring applications will still probably want
> to be notified.
   Sure, but in that case just create an event CORRECTED_CHECKSUM_ERROR and
use that. Then userspace knows what it should do with the event. No need to
hide it behind warning / error category.

								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>

  reply	other threads:[~2015-04-17 13:41 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
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 [this message]
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=20150417134144.GA23905@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger.kernel@dilger.ca \
    --cc=ahferroin7@gmail.com \
    --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.