[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200714110011.GB16178@lst.de>
Date: Tue, 14 Jul 2020 13:00:11 +0200
From: Christoph Hellwig <hch@....de>
To: Matthew Wilcox <willy@...radead.org>
Cc: Christoph Hellwig <hch@....de>, Dave Chinner <david@...morbit.com>,
Goldwyn Rodrigues <rgoldwyn@...e.de>,
Damien Le Moal <damien.lemoal@....com>,
Naohiro Aota <naohiro.aota@....com>,
Johannes Thumshirn <jth@...nel.org>,
linux-btrfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
cluster-devel@...hat.com, linux-ext4@...r.kernel.org,
linux-xfs@...r.kernel.org
Subject: Re: [PATCH 2/2] iomap: fall back to buffered writes for
invalidation failures
On Mon, Jul 13, 2020 at 12:55:09PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 13, 2020 at 09:46:33AM +0200, Christoph Hellwig wrote:
> > Failing to invalid the page cache means data in incoherent, which is
> > a very bad state for the system. Always fall back to buffered I/O
> > through the page cache if we can't invalidate mappings.
>
> Is that the right approach though? I don't have a full picture in my head,
> but wouldn't we be better off marking these pages as !Uptodate and doing
> the direct I/O?
Isn't that a problem if e.g. pages are mapped into userspace and mlocked?
Powered by blists - more mailing lists