Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
        Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
        Kingdom.
        Registered in England and Wales under Company Registration No. 3798903
From:   David Howells <dhowells@redhat.com>
In-Reply-To: <20201208003117.342047-1-krisman@collabora.com>
References: <20201208003117.342047-1-krisman@collabora.com>
To:     Gabriel Krisman Bertazi <krisman@collabora.com>
Cc:     dhowells@redhat.com, viro@zeniv.linux.org.uk, tytso@mit.edu,
        khazhy@google.com, adilger.kernel@dilger.ca,
        linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        kernel@collabora.com
Subject: Re: [PATCH 0/8] Superblock Notifications
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <953339.1607432374.1@warthog.procyon.org.uk>
Date:   Tue, 08 Dec 2020 12:59:34 +0000
Message-ID: <953340.1607432374@warthog.procyon.org.uk>
Precedence: bulk

Gabriel Krisman Bertazi <krisman@collabora.com> wrote:

> After the two previous RFCs this is an attempt to get the ball spinning
> again.
> 
> The problem I'm trying to solve is providing an interface to monitor
> filesystem errors.  This patchset includes an example implementation of
> ext4 error notification.  This goes obviously on top of the watch_queue
> mechanism.

Thanks for picking this up and advancing it.

> Regarding the buffer overrun issue that would require fsinfo or another
> method to expose counters, I think they can be added at a later date
> with no change to what this patch series attempts to do, therefore I'm
> proposing we don't wait for fsinfo before getting this merged.

That's fine, but anyone wanting to use this will need to be aware that
overruns are a problem.

David