From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965203AbbDQQIS (ORCPT ); Fri, 17 Apr 2015 12:08:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54623 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933074AbbDQQIQ (ORCPT ); Fri, 17 Apr 2015 12:08:16 -0400 Message-ID: <55312FEA.3030905@redhat.com> Date: Fri, 17 Apr 2015 17:08:10 +0100 From: John Spray User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jan Kara CC: Austin S Hemmelgarn , Beata Michalska , 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 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> <55311DE2.9000901@redhat.com> <20150417154351.GA26736@quack.suse.cz> In-Reply-To: <20150417154351.GA26736@quack.suse.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/04/2015 16:43, Jan Kara wrote: > On Fri 17-04-15 15:51:14, John Spray wrote: >> On 17/04/2015 14:23, Austin S Hemmelgarn wrote: >> >>> 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. >> Another key differentiation IMHO is between transient errors (like >> server is unavailable in a distributed filesystem) that will block >> the filesystem but might clear on their own, vs. permanent errors >> like unreadable drives that definitely will not clear until the >> administrator takes some action. It's usually a reasonable >> approximation to call transient issues warnings, and permanent >> issues errors. > So you can have events like FS_UNAVAILABLE and FS_AVAILABLE but what use > would this have? I wouldn't like the interface to be dumping ground for > random crap - we have dmesg for that :). In that case I'm confused -- why would ENOSPC be an appropriate use of this interface if the mount being entirely blocked would be inappropriate? Isn't being unable to service any I/O a more fundamental and severe thing than being up and healthy but full? Were you intending the interface to be exclusively for data integrity issues like checksum failures, rather than more general events about a mount that userspace would probably like to know about? John From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Spray Subject: Re: [RFC 1/4] fs: Add generic file system event notifications Date: Fri, 17 Apr 2015 17:08:10 +0100 Message-ID: <55312FEA.3030905@redhat.com> 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> <55311DE2.9000901@redhat.com> <20150417154351.GA26736@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Austin S Hemmelgarn , Beata Michalska , 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-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jan Kara Return-path: In-Reply-To: <20150417154351.GA26736-+0h/O2h83AeN3ZZ/Hiejyg@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On 17/04/2015 16:43, Jan Kara wrote: > On Fri 17-04-15 15:51:14, John Spray wrote: >> On 17/04/2015 14:23, Austin S Hemmelgarn wrote: >> >>> 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. >> Another key differentiation IMHO is between transient errors (like >> server is unavailable in a distributed filesystem) that will block >> the filesystem but might clear on their own, vs. permanent errors >> like unreadable drives that definitely will not clear until the >> administrator takes some action. It's usually a reasonable >> approximation to call transient issues warnings, and permanent >> issues errors. > So you can have events like FS_UNAVAILABLE and FS_AVAILABLE but what use > would this have? I wouldn't like the interface to be dumping ground for > random crap - we have dmesg for that :). In that case I'm confused -- why would ENOSPC be an appropriate use of this interface if the mount being entirely blocked would be inappropriate? Isn't being unable to service any I/O a more fundamental and severe thing than being up and healthy but full? Were you intending the interface to be exclusively for data integrity issues like checksum failures, rather than more general events about a mount that userspace would probably like to know about? John From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by kanga.kvack.org (Postfix) with ESMTP id E15426B0032 for ; Fri, 17 Apr 2015 12:08:18 -0400 (EDT) Received: by qcyk17 with SMTP id k17so26458384qcy.1 for ; Fri, 17 Apr 2015 09:08:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id 186si12039148qhw.24.2015.04.17.09.08.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2015 09:08:17 -0700 (PDT) Message-ID: <55312FEA.3030905@redhat.com> Date: Fri, 17 Apr 2015 17:08:10 +0100 From: John Spray MIME-Version: 1.0 Subject: Re: [RFC 1/4] fs: Add generic file system event notifications 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> <55311DE2.9000901@redhat.com> <20150417154351.GA26736@quack.suse.cz> In-Reply-To: <20150417154351.GA26736@quack.suse.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jan Kara Cc: Austin S Hemmelgarn , Beata Michalska , 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 17/04/2015 16:43, Jan Kara wrote: > On Fri 17-04-15 15:51:14, John Spray wrote: >> On 17/04/2015 14:23, Austin S Hemmelgarn wrote: >> >>> 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. >> Another key differentiation IMHO is between transient errors (like >> server is unavailable in a distributed filesystem) that will block >> the filesystem but might clear on their own, vs. permanent errors >> like unreadable drives that definitely will not clear until the >> administrator takes some action. It's usually a reasonable >> approximation to call transient issues warnings, and permanent >> issues errors. > So you can have events like FS_UNAVAILABLE and FS_AVAILABLE but what use > would this have? I wouldn't like the interface to be dumping ground for > random crap - we have dmesg for that :). In that case I'm confused -- why would ENOSPC be an appropriate use of this interface if the mount being entirely blocked would be inappropriate? Isn't being unable to service any I/O a more fundamental and severe thing than being up and healthy but full? Were you intending the interface to be exclusively for data integrity issues like checksum failures, rather than more general events about a mount that userspace would probably like to know about? John -- 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