linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viacheslav Dubeyko <slava@dubeyko.com>
To: Gabriel Krisman Bertazi <krisman@collabora.com>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	jack@suse.com, viro@zeniv.linux.org.uk, amir73il@gmail.com,
	dhowells@redhat.com, david@fromorbit.com,
	darrick.wong@oracle.com, khazhy@google.com,
	Linux FS devel list <linux-fsdevel@vger.kernel.org>,
	kernel@collabora.com
Subject: Re: [RFC] Filesystem error notifications proposal
Date: Wed, 20 Jan 2021 20:01:51 -0800	[thread overview]
Message-ID: <4474C4D0-87E2-4437-9546-9842CC2645D2@dubeyko.com> (raw)
In-Reply-To: <87lfcne59g.fsf@collabora.com>



> On Jan 20, 2021, at 12:13 PM, Gabriel Krisman Bertazi <krisman@collabora.com> wrote:
> 
> 
> My apologies for the long email.
> 
> Please let me know your thoughts.
> 
> 1 Summary
> =========
> 
>  I'm looking for a filesystem-agnostic mechanism to report filesystem
>  errors to a monitoring tool in userspace.  I experimented first with
>  the watch_queue API but decided to move to fanotify for a few reasons.
> 

I don’t quite follow what the point in such user-space tool because anybody can take a look into the syslog. Even it is possible to grep error messages related to particular file system. What’s the point of such tool? I can see some point to report about file system corruption but you are talking about any error message. Moreover, it could be not trivial to track corruption even on file system driver’s side.

> 
> 2 Background
> ============
> 
>  I submitted a first set of patches, based on David Howells' original
>  superblock notifications patchset, that I expanded into error
>  reporting and had an example implementation for ext4.  Upstream review
>  has revealed a few design problems:
> 
>  - Including the "function:line" tuple in the notification allows the
>    uniquely identification of the error origin but it also ties the
>    decodification of the error to the source code, i.e. <function:line>
>    is expected to change between releases.
> 

Error message itself could identify the location without the necessity to know <function:line>. Only specially generated UID can be good solution, I suppose.

>  - Useful debug data (inode number, block group) have formats specific
>    to the filesystems, and my design wouldn't be expansible to
>    filesystems other than ext4.
> 

Different file system volumes associate inode ids with completely different objects. So, if you haven’t access to the same volume then this information could be useless. What’s the point to share these details? Sometimes, to track the issue in file system driver requires to know much more details related to particular volume.

Finally, what’s the concrete use-cases that this user-space tool can be used? Currently, I don’t see any point to use this tool. The syslog is much more productive way to debug and to investigate the issues in file system driver.

Thanks,
Viacheslav Dubeyko.


  reply	other threads:[~2021-01-21  4:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 20:13 [RFC] Filesystem error notifications proposal Gabriel Krisman Bertazi
2021-01-21  4:01 ` Viacheslav Dubeyko [this message]
2021-01-21 11:44 ` Jan Kara
2021-01-21 13:27   ` Amir Goldstein
2021-01-21 18:56   ` Gabriel Krisman Bertazi
2021-01-21 22:44 ` Theodore Ts'o
2021-01-22  0:44   ` Gabriel Krisman Bertazi
2021-01-22  7:36     ` Amir Goldstein
2021-02-02 20:51       ` Gabriel Krisman Bertazi
2021-01-28 22:28     ` Theodore Ts'o
2021-02-02 20:26       ` Gabriel Krisman Bertazi
2021-02-02 22:34         ` Theodore Ts'o
2021-02-08 18:49           ` Gabriel Krisman Bertazi
2021-02-08 22:19             ` Dave Chinner
2021-02-09  1:08               ` Theodore Ts'o
2021-02-09  5:12                 ` Khazhismel Kumykov
2021-02-09  8:55                 ` Dave Chinner
2021-02-09 17:57                   ` Theodore Ts'o
2021-02-10  0:52                     ` Darrick J. Wong
2021-02-10  2:21                       ` Theodore Ts'o
2021-02-10  2:32                         ` Darrick J. Wong
2021-02-09 17:35               ` Jan Kara
2021-02-10  0:22                 ` Darrick J. Wong
2021-02-10  7:46                 ` Dave Chinner
2021-02-10  0:49               ` Darrick J. Wong
2021-02-10  0:09 ` Darrick J. Wong
2021-02-10  7:23   ` Amir Goldstein
2021-02-10 23:29   ` Gabriel Krisman Bertazi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4474C4D0-87E2-4437-9546-9842CC2645D2@dubeyko.com \
    --to=slava@dubeyko.com \
    --cc=amir73il@gmail.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=dhowells@redhat.com \
    --cc=jack@suse.com \
    --cc=kernel@collabora.com \
    --cc=khazhy@google.com \
    --cc=krisman@collabora.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).