From: Christoph Hellwig <hch@lst.de>
To: dsterba@suse.cz, Qu Wenruo <quwenruo.btrfs@gmx.com>,
Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@lst.de>,
clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH] btrfs: remove btrfs_writepage_cow_fixup
Date: Wed, 29 Jun 2022 09:58:37 +0200 [thread overview]
Message-ID: <20220629075837.GA22346@lst.de> (raw)
In-Reply-To: <20220628115356.GB20633@suse.cz>
On Tue, Jun 28, 2022 at 01:53:56PM +0200, David Sterba wrote:
> This would work only for the higher level API where eg. RDMA notifies
> the filesystem, but there's still the s390 case that is part of the
> hardware architecture. The fixup worker is there as a safety for all
> other cases, I'm not fine removing or ignoring it.
I'd really like to have a confirmation of this whole s390 theory.
s390 does treat some dirtying different than the other architectures,
but none of that should leak into the file system API if any way that
bypasses ->page_mkwrite.
Because if it did most file systems would be completely broken on
s390.
next prev parent reply other threads:[~2022-06-29 7:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220624122334.80603-1-hch@lst.de>
[not found] ` <20220624124913.GS20633@twin.jikos.cz>
2022-06-24 13:12 ` [PATCH] btrfs: remove btrfs_writepage_cow_fixup Qu Wenruo
2022-06-24 13:27 ` David Sterba
2022-06-24 13:50 ` Qu Wenruo
[not found] ` <7c30b6a4-e628-baea-be83-6557750f995a@gmx.com>
[not found] ` <20220624125118.GA789@lst.de>
[not found] ` <20220624130750.cu26nnm6hjrru4zd@quack3.lan>
[not found] ` <20220625091143.GA23118@lst.de>
[not found] ` <20220627101914.gpoz7f6riezkolad@quack3.lan>
[not found] ` <e73be42e-fce5-733a-310d-db9dc5011796@gmx.com>
[not found] ` <20220628115356.GB20633@suse.cz>
2022-06-29 7:58 ` Christoph Hellwig [this message]
2022-07-05 14:21 ` Gerald Schaefer
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=20220629075837.GA22346@lst.de \
--to=hch@lst.de \
--cc=agordeev@linux.ibm.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/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).