From: John Spray <john.spray@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>,
Beata Michalska <b.michalska@samsung.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
Date: Fri, 17 Apr 2015 17:08:10 +0100 [thread overview]
Message-ID: <55312FEA.3030905@redhat.com> (raw)
In-Reply-To: <20150417154351.GA26736@quack.suse.cz>
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-04-17 16:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-15 7:15 [RFC 0/4] Generic file system events interface Beata Michalska
2015-04-15 7:15 ` [RFC 1/4] fs: Add generic file system event notifications Beata Michalska
2015-04-15 19:25 ` Darrick J. Wong
2015-04-16 8:22 ` Beata Michalska
2015-04-17 8:48 ` Jan Kara
2015-04-16 3:46 ` Eric Sandeen
2015-04-16 8:41 ` Beata Michalska
2015-04-16 20:10 ` Hugh Dickins
2015-04-17 9:10 ` Beata Michalska
2015-04-16 21:56 ` Heinrich Schuchardt
2015-04-17 9:46 ` Beata Michalska
2015-04-17 11:58 ` Jan Kara
2015-04-17 11:31 ` Jan Kara
2015-04-17 13:04 ` Beata Michalska
2015-04-17 13:15 ` Beata Michalska
2015-04-17 13:16 ` Jan Kara
2015-04-17 13:23 ` Austin S Hemmelgarn
2015-04-17 13:41 ` Jan Kara
2015-04-17 14:51 ` John Spray
2015-04-17 15:43 ` Jan Kara
2015-04-17 16:08 ` John Spray [this message]
2015-04-17 16:22 ` Jan Kara
2015-04-17 16:29 ` Austin S Hemmelgarn
2015-04-17 16:39 ` Jan Kara
2015-04-17 17:37 ` John Spray
2015-04-17 22:37 ` Andreas Dilger
2015-04-17 16:25 ` Beata Michalska
2015-04-17 22:44 ` Andreas Dilger
2015-04-20 8:56 ` Beata Michalska
2015-04-20 10:32 ` Jan Kara
2015-04-15 7:15 ` [RFC 2/4] ext4: Add helper function to mark group as corrupted Beata Michalska
2015-04-15 7:15 ` [RFC 3/4] ext4: Add support for generic FS events Beata Michalska
2015-04-15 19:18 ` Darrick J. Wong
2015-04-16 8:02 ` Beata Michalska
2015-04-15 7:15 ` [RFC 4/4] shmem: " Beata Michalska
2015-04-17 8:17 ` [RFC 0/4] Generic file system events interface Jan Kara
2015-04-17 9:10 ` Beata Michalska
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=55312FEA.3030905@redhat.com \
--to=john.spray@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=ahferroin7@gmail.com \
--cc=b.michalska@samsung.com \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=kmpark@infradead.org \
--cc=kyungmin.park@samsung.com \
--cc=lczerner@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tytso@mit.edu \
/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).