From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932692AbbDQNly (ORCPT ); Fri, 17 Apr 2015 09:41:54 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36315 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932173AbbDQNls (ORCPT ); Fri, 17 Apr 2015 09:41:48 -0400 Date: Fri, 17 Apr 2015 15:41:44 +0200 From: Jan Kara To: Austin S Hemmelgarn Cc: Beata Michalska , Jan Kara , 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-api@vger.kernel.org Subject: Re: [RFC 1/4] fs: Add generic file system event notifications Message-ID: <20150417134144.GA23905@quack.suse.cz> References: <1429082147-4151-1-git-send-email-b.michalska@samsung.com> <1429082147-4151-2-git-send-email-b.michalska@samsung.com> <20150417113110.GD3116@quack.suse.cz> <553104E5.2040704@samsung.com> <55310957.3070101@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55310957.3070101@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 SUSE Labs, CR From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by kanga.kvack.org (Postfix) with ESMTP id 9B69E6B0075 for ; Fri, 17 Apr 2015 09:41:48 -0400 (EDT) Received: by qku63 with SMTP id 63so152809366qku.3 for ; Fri, 17 Apr 2015 06:41:48 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id k8si3030810wia.75.2015.04.17.06.41.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Apr 2015 06:41:47 -0700 (PDT) Date: Fri, 17 Apr 2015 15:41:44 +0200 From: Jan Kara Subject: Re: [RFC 1/4] fs: Add generic file system event notifications Message-ID: <20150417134144.GA23905@quack.suse.cz> References: <1429082147-4151-1-git-send-email-b.michalska@samsung.com> <1429082147-4151-2-git-send-email-b.michalska@samsung.com> <20150417113110.GD3116@quack.suse.cz> <553104E5.2040704@samsung.com> <55310957.3070101@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55310957.3070101@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Austin S Hemmelgarn Cc: Beata Michalska , Jan Kara , 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-api@vger.kernel.org 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 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: email@kvack.org