From: Christoph Hellwig <hch@lst.de>
To: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Christoph Hellwig <hch@lst.de>,
Naohiro Aota <Naohiro.Aota@wdc.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: error writing primary super block on zoned btrfs
Date: Tue, 19 Jul 2022 17:13:45 +0200 [thread overview]
Message-ID: <20220719151345.GA21932@lst.de> (raw)
In-Reply-To: <PH0PR04MB74161E9598C27B8CEA10F53F9B8F9@PH0PR04MB7416.namprd04.prod.outlook.com>
On Tue, Jul 19, 2022 at 07:53:45AM +0000, Johannes Thumshirn wrote:
> Ha but zoned btrfs uses two zones as a ringbuffer for its super-block, could
> it be, that we're accumulating too many page references somewhere? And then it
> behaves like having millions of filesystems mounted?
That fact the superblock moves for zoned devices probably has
something to do with it. But the whole code leaves me really puzzling.
Why does wait_dev_supers even do a find_get_page vs just stashing
three page pointers away in the btrfs_device structure?
Why does this abuse wait_on_page_locked vs using a completion?
Why does the code count errors while only an error on the primary
superblock has any consequences?
What is the point of the secodary superblocks if they aren't written
on fsync?
How does just setting the whole page uptodat work on file systems
with a block size smaller than the page size where we don't know
what is in the rest of the page?
next prev parent reply other threads:[~2022-07-19 15:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-18 5:49 error writing primary super block on zoned btrfs Christoph Hellwig
2022-07-18 12:28 ` Matthew Wilcox
2022-07-18 12:33 ` Christoph Hellwig
2022-07-19 7:53 ` Johannes Thumshirn
2022-07-19 15:13 ` Christoph Hellwig [this message]
2022-07-19 21:32 ` David Sterba
2022-07-25 17:36 ` 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=20220719151345.GA21932@lst.de \
--to=hch@lst.de \
--cc=Johannes.Thumshirn@wdc.com \
--cc=Naohiro.Aota@wdc.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.