From: Damien Le Moal <dlemoal@kernel.org>
To: Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org
Cc: Christoph Hellwig <hch@lst.de>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: [PATCH v2] block: Increase BLK_DEF_MAX_SECTORS_CAP
Date: Wed, 18 Jun 2025 15:00:45 +0900 [thread overview]
Message-ID: <20250618060045.37593-1-dlemoal@kernel.org> (raw)
Back in 2015, commit d2be537c3ba3 ("block: bump BLK_DEF_MAX_SECTORS to
2560") increased the default maximum size of a block device I/O to 2560
sectors (1280 KiB) to "accommodate a 10-data-disk stripe write with
chunk size 128k". This choice is rather arbitrary and since then,
improvements to the block layer have software RAID drivers correctly
advertize their stripe width through chunk_sectors and abuses of
BLK_DEF_MAX_SECTORS_CAP by drivers (to set the HW limit rather than the
default user controlled maximum I/O size) have been fixed.
Since many block devices can benefit from a larger value of
BLK_DEF_MAX_SECTORS_CAP, and in particular HDDs, increase this value to
be 4MiB, or 8192 sectors.
And given that BLK_DEF_MAX_SECTORS_CAP is only used in the block layer
and should not be used by drivers directly, move this macro definition
to the block layer internal header file block/blk.h.
Suggested-by: Martin K . Petersen <martin.petersen@oracle.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
---
Changes from v1:
- Move BLK_DEF_MAX_SECTORS_CAP definition to block/blk.h
- Define the macro value using SZ_4M to make it more readable
- Added review tag
block/blk.h | 9 +++++++++
include/linux/blkdev.h | 9 ---------
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/block/blk.h b/block/blk.h
index 37ec459fe656..1141b343d0b5 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -13,6 +13,15 @@
struct elevator_type;
+/*
+ * Default upper limit for the software max_sectors limit used for regular I/Os.
+ * This can be increased through sysfs.
+ *
+ * This should not be confused with the max_hw_sector limit that is entirely
+ * controlled by the block device driver, usually based on hardware limits.
+ */
+#define BLK_DEF_MAX_SECTORS_CAP (SZ_4M >> SECTOR_SHIFT)
+
#define BLK_DEV_MAX_SECTORS (LLONG_MAX >> 9)
#define BLK_MIN_SEGMENT_SIZE 4096
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 85aab8bc96e7..c2b3ddea8b6d 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1231,15 +1231,6 @@ enum blk_default_limits {
BLK_SEG_BOUNDARY_MASK = 0xFFFFFFFFUL,
};
-/*
- * Default upper limit for the software max_sectors limit used for
- * regular file system I/O. This can be increased through sysfs.
- *
- * Not to be confused with the max_hw_sector limit that is entirely
- * controlled by the driver, usually based on hardware limits.
- */
-#define BLK_DEF_MAX_SECTORS_CAP 2560u
-
static inline struct queue_limits *bdev_limits(struct block_device *bdev)
{
return &bdev_get_queue(bdev)->limits;
--
2.49.0
next reply other threads:[~2025-06-18 6:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-18 6:00 Damien Le Moal [this message]
2025-06-18 6:17 ` [PATCH v2] block: Increase BLK_DEF_MAX_SECTORS_CAP Hannes Reinecke
2025-06-18 8:51 ` Johannes Thumshirn
2025-06-18 9:06 ` John Garry
2025-06-18 9:47 ` Damien Le Moal
2025-06-18 10:19 ` Martin K. Petersen
2025-06-23 13:40 ` Christoph Hellwig
2025-06-24 16:49 ` Jens Axboe
2025-08-27 7:07 ` Sebastian Andrzej Siewior
2025-08-27 7:38 ` Christoph Hellwig
2025-08-27 7:52 ` Sebastian Andrzej Siewior
2025-08-27 8:00 ` Christoph Hellwig
2025-08-27 8:03 ` Damien Le Moal
2025-08-27 8:01 ` Damien Le Moal
2025-08-27 8:42 ` Sebastian Andrzej Siewior
2025-08-27 9:01 ` Damien Le Moal
2025-08-27 10:16 ` Sebastian Andrzej Siewior
2026-03-31 12:02 ` Mira Limbeck
2026-03-31 12:30 ` Mira Limbeck
2026-03-31 19:48 ` Damien Le Moal
2026-04-01 10:32 ` Mira Limbeck
2026-04-01 20:02 ` Damien Le Moal
2026-04-01 20:55 ` Keith Busch
2026-04-01 23:31 ` Damien Le Moal
2026-04-02 14:33 ` Friedrich Weber
2026-04-02 15:03 ` Keith Busch
2026-04-02 23:25 ` Damien Le Moal
2026-04-03 13:51 ` Keith Busch
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=20250618060045.37593-1-dlemoal@kernel.org \
--to=dlemoal@kernel.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=martin.petersen@oracle.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 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.