public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: "Holger Hoffstätte" <holger@applied-asynchrony.com>
Cc: xfs <linux-xfs@vger.kernel.org>
Subject: Re: [RFC PATCH] iomap: report collisions between directio and buffered writes to userspace
Date: Wed, 15 Nov 2017 10:54:28 -0800	[thread overview]
Message-ID: <20171115185428.GF5119@magnolia> (raw)
In-Reply-To: <8aa299eb-e1c4-6d8e-f536-bf764661e1b2@applied-asynchrony.com>

On Wed, Nov 15, 2017 at 02:16:01PM +0100, Holger Hoffstätte wrote:
> On 11/14/17 22:46, Darrick J. Wong wrote:
> (snip)
> > +static void iomap_warn_stale_pagecache(struct inode *inode)
> > +{
> > +	errseq_set(&inode->i_mapping->wb_err, -EIO);
> > +	pr_crit_ratelimited("Stale pagecache contents after collision "
> > +			    "between direct and buffered write!\n");
> > +}
> 
> In this form the error message is IMHO useless since it tells me
> neither the file in question nor the misbehaving application.
> "Something went wrong somewhere" is not actionable information
> and in practice will only be ignored.
> 
> Since you already have the inode in question at hand, print at least
> the full path + filename so that it's clear where things are going
> wrong. Usually that will let people deduce which application is
> misbehaving.

The whole point of the errseq_set call in this patch is to record the
write collision so that all the writers of this file will receive an EIO
the next time they try to flush the file.  You can pinpoint exactly
which fd(s) in which application(s) caused the problem.  The old dmesg
spew only captured which program issued the dio write.

(And the whole point of this patch is to see what people think about
that change of behavior w.r.t. us no longer letting userspace silently
corrupt the file...)

--D

> -h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-11-15 18:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-14 21:46 [RFC PATCH] iomap: report collisions between directio and buffered writes to userspace Darrick J. Wong
2017-11-15 12:12 ` Brian Foster
2017-11-15 18:46   ` Darrick J. Wong
2017-11-15 13:16 ` Holger Hoffstätte
2017-11-15 18:54   ` Darrick J. Wong [this message]
2017-11-15 19:35     ` Holger Hoffstätte
2017-11-15 20:53       ` Dave Chinner

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=20171115185428.GF5119@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=holger@applied-asynchrony.com \
    --cc=linux-xfs@vger.kernel.org \
    /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