Message-id: <55313401.5080008@samsung.com>
Date: Fri, 17 Apr 2015 18:25:37 +0200
From: Beata Michalska <b.michalska@samsung.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804
 Thunderbird/17.0.8
MIME-version: 1.0
To: John Spray <john.spray@redhat.com>
Cc: Jan Kara <jack@suse.cz>, Austin S Hemmelgarn <ahferroin7@gmail.com>,
        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
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> <55312FEA.3030905@redhat.com>
In-reply-to: <55312FEA.3030905@redhat.com>
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2279
Lines: 44

On 04/17/2015 06:08 PM, John Spray wrote:
> 
> 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
> 

I think we should support both and leave the decision on what
is to be reported or not to particular file systems keeping it
to a reasonable extent, of course. The interface should hand it over
to user space - acting as a go-between. I would though avoid
any filesystem specific events (when it comes to specifying those),
keeping it as generic as possible.


BR
Beata
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/