Hi,
On 27/05/2020 11:02, Andrew Price wrote:
On 27/05/2020 09:53, Steven Whitehouse wrote:
Hi,
On 27/05/2020 09:29, Andrew Price wrote:
Some devices report an optimal_io_size of 512 instead of 0 when it's
not
larger than the minimum_io_size. Currently mkfs.gfs2 uses the non-zero
value to choose the block size, which is almost certainly not what we
want when it's 512. Update the suitability check for optimal_io_size to
avoid using it when it's the same as minimum_io_size. The effect is
that we fall back to using the default block size, 4096.
Resolves: rhbz#1839219
Signed-off-by: Andrew Price <anpr...@redhat.com>
What about for other sizes? We don't really want to select a block
size to be anything other than 4k in most cases, even if the block
device offers a lower minimum/optimal I/O size,
I think it would be unusual for a device to have an optimal_io_size >
512 and < 4K, and I expect it's only 512 for the tested device because
of some design or configuration error, so we're still covering most
cases anyway. I figured that any other optimal_io_size is likely to be
one that's there for a good reason and so we should probably use it
(if suitable).
That's just my reasoning for this patch though. I can see the value in
ignoring optimal_io_size < 4K, but it poses the question of whether
there's any value in allowing mkfs.gfs2 to create < 4K block size
filesystems at all.
Andy
By default, I can't see any reason why we'd want a block sizes less than
4k. We might want to allow someone to do that for special cases, but
generally the lower block sizes cause issue with larger file sizes, due
to the increased height of the metadata tree. As such we should try and
avoid them, and ignoring all hints of below 4k seems like a sensible plan.
If someone specifically requests a smaller block size on the command
line, then that is another thing, but we should try and protect people
from devices which advertise really small optimal I/O sizes. Really we
should be using that in combination with the alignment information when
laying out the larger structures on disk, and not using it for selecting
the block size - assuming again that these sizes have been set by the
device to something sensible in the first place,
Steve.
---
gfs2/mkfs/main_mkfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gfs2/mkfs/main_mkfs.c b/gfs2/mkfs/main_mkfs.c
index 846b341f..8b97f3d2 100644
--- a/gfs2/mkfs/main_mkfs.c
+++ b/gfs2/mkfs/main_mkfs.c
@@ -505,7 +505,7 @@ static unsigned choose_blocksize(struct
mkfs_opts *opts)
}
if (!opts->got_bsize && got_topol) {
if (dev->optimal_io_size <= getpagesize() &&
- dev->optimal_io_size >= dev->minimum_io_size)
+ dev->optimal_io_size > dev->minimum_io_size)
bsize = dev->optimal_io_size;
else if (dev->physical_sector_size <= getpagesize() &&
dev->physical_sector_size >= GFS2_DEFAULT_BSIZE)
