From: Christopher Unkel <cunkel@drivescale.com>
To: linux-raid@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Song Liu <song@kernel.org>,
cunkel@drivescale.com
Subject: [PATCH 3/3] md: pad writes to end of bitmap to physical blocks
Date: Thu, 22 Oct 2020 20:31:30 -0700 [thread overview]
Message-ID: <20201023033130.11354-4-cunkel@drivescale.com> (raw)
In-Reply-To: <20201023033130.11354-1-cunkel@drivescale.com>
Writes of the last page of the bitmap are padded out to the next logical
block boundary. However, they are not padded out to the next physical
block boundary, so the writes may be less than a physical block. On a
"512e" disk (logical block 512 bytes, physical block 4k) and if the last
page of the bitmap is less than 3584 bytes, this means that writes of
the last bitmap page hit the 512-byte emulation.
Respect the physical block boundary as long as the resulting write
doesn't run into other data, and is no longer than a page. (If the
physical block size is larger than a page no bitmap write will respect
the physical block boundaries.)
Signed-off-by: Christopher Unkel <cunkel@drivescale.com>
---
drivers/md/md-bitmap.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index 600b89d5a3ad..21af5f94d495 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -264,10 +264,18 @@ static int write_sb_page(struct bitmap *bitmap, struct page *page, int wait)
if (page->index == store->file_pages-1) {
int last_page_size = store->bytes & (PAGE_SIZE-1);
+ int pb_aligned_size;
if (last_page_size == 0)
last_page_size = PAGE_SIZE;
size = roundup(last_page_size,
bdev_logical_block_size(bdev));
+ pb_aligned_size = roundup(last_page_size,
+ bdev_physical_block_size(bdev));
+ if (pb_aligned_size > size
+ && pb_aligned_size <= PAGE_SIZE
+ && sb_write_alignment_ok(mddev, rdev, page, offset,
+ pb_aligned_size))
+ size = pb_aligned_size;
}
/* Just make sure we aren't corrupting data or
* metadata
--
2.17.1
next prev parent reply other threads:[~2020-10-23 3:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 3:31 [PATCH 0/3] mdraid sb and bitmap write alignment on 512e drives Christopher Unkel
2020-10-23 3:31 ` [PATCH 1/3] md: align superblock writes to physical blocks Christopher Unkel
2020-10-23 5:46 ` Song Liu
2020-10-23 8:29 ` Christoph Hellwig
2020-10-23 3:31 ` [PATCH 2/3] md: factor sb write alignment check into function Christopher Unkel
2020-10-23 3:31 ` Christopher Unkel [this message]
2020-10-23 5:41 ` [PATCH 0/3] mdraid sb and bitmap write alignment on 512e drives Song Liu
2020-10-23 7:03 ` Chris Unkel
2020-11-02 7:04 ` Xiao Ni
2020-11-02 18:59 ` Chris Unkel
2020-11-03 8:32 ` Xiao Ni
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=20201023033130.11354-4-cunkel@drivescale.com \
--to=cunkel@drivescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=song@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;
as well as URLs for NNTP newsgroup(s).