Re: [RFC 1/4] fs: Add generic file system event notifications

[Austin S Hemmelgarn]

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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature