From: Josef Bacik <josef@toxicpanda.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 0/3] fixup work fixes
Date: Tue, 21 Jan 2020 11:51:41 -0500 [thread overview]
Message-ID: <20200121165144.2174309-1-josef@toxicpanda.com> (raw)
This series is to address a few issues with the fixup worker we hit in
production.
The first of this is a resend of
Btrfs: keep pages dirty when using
I've cleaned this up based on the feedback and added a bunch more comments to
make it clear what is happening and why we're doing it.
The next patch is a cleanup that is made possible by the previous patch, again
to clear up the fixup workers job.
btrfs: drop the -EBUSY case in __extent_writepage_io
And finally the deadlock fix that I submitted earlier. I noticed while trying
to backport this onto our kernel that we had changed the error case with the
above patch from Chris, and actually we really, really need Chris's fix as well.
There is also a change in the error handling from v1 where we now set the page
error properly but only once we've locked the page and verified we're still
responsible for COW'ing the page. Thanks,
Josef
next reply other threads:[~2020-01-21 16:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 16:51 Josef Bacik [this message]
2020-01-21 16:51 ` [PATCH 1/3] Btrfs: keep pages dirty when using btrfs_writepage_fixup_worker Josef Bacik
2020-01-21 16:51 ` [PATCH 2/3] btrfs: drop the -EBUSY case in __extent_writepage_io Josef Bacik
2020-01-21 16:51 ` [PATCH 3/3][v2] btrfs: do not do delalloc reservation under page lock Josef Bacik
2020-01-21 19:34 ` [PATCH][v3] " Josef Bacik
2020-01-29 15:12 ` David Sterba
2020-01-29 15:11 ` [PATCH 0/3] fixup work fixes David Sterba
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=20200121165144.2174309-1-josef@toxicpanda.com \
--to=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@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