Bug 1839219
| Summary: | mkfs.gfs2: default block size is reduced by topology | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Nate Straz <nstraz> | |
| Component: | gfs2-utils | Assignee: | Andrew Price <anprice> | |
| Status: | CLOSED ERRATA | QA Contact: | cluster-qe <cluster-qe> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 8.3 | CC: | bperkins, cluster-maint, gfs2-maint, sbradley | |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
|
| Target Release: | 8.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | gfs2-utils-3.2.0-8.el8 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1853625 (view as bug list) | Environment: | ||
| Last Closed: | 2020-11-04 02:01:07 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1853625 | |||
|
Description
Nate Straz
2020-05-22 19:02:43 UTC
(In reply to Nate Straz from comment #0) > Is this behavior expected Well if the system is telling mkfs.gfs2 that its optimal i/o size is 512 then that's the fastest i/o unit to be using, right? :) We've been using optimal_io_size in our block size decision making the same way since 2010: https://bugzilla.redhat.com/show_bug.cgi?id=519491#c22 > and is it desired? I suspect not. We might be able to improve on this logic: if (!opts->got_bsize && got_topol) { if (dev->optimal_io_size <= getpagesize() && dev->optimal_io_size >= dev->minimum_io_size) bsize = dev->optimal_io_size; It could simply be that we need - dev->optimal_io_size >= dev->minimum_io_size) + dev->optimal_io_size > dev->minimum_io_size) to disregard optimal_io_size when it's equal to the minimum. Here's a build with that change if you want to test it out: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=28831792 Could you run other mkfses against the device and see what they do with the topology? And is it safe to assume that the page size is 4K in that environment? For reference: http://people.redhat.com/msnitzer/docs/io-limits.txt I will test this today. I will point out two quick things: 1) the system page size variable is set to 4096 2) the identical RHEL7 setup (which does not have the optimal I/O size set for NVMe devices) does format at 4096 and has shown no problems I can verify that with gfs2-utils-3.2.0-7.el8.bz1839219 GFS2 mounting in AWS (NVMe) on RHEL8 is now working. I have also verified that this build didn't break RHEL8 GFS2 mounting on Aliyun (VirtIO) or Azure (SCSI). For documentation purposes, here is the topology for shared block devices across cloud providers and RHEL versions: Provider RHEL IF NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME Aliyun 7 VirtIO vdb 0 512 0 512 512 1 mq-deadline 256 4096 0B Aliyun 8 VIrtIO vdb 0 512 0 512 512 1 mq-deadline 256 4096 0B AWS 7 NVMe nvme1n1 0 512 0 512 512 0 none 31 128 0B AWS 8 NVMe nvme1n1 0 512 512 512 512 0 none 31 128 0B Azure 7 SCSI sdc 0 4096 0 4096 512 1 deadline 128 4096 0B Azure 8 SCSI sdc 0 4096 0 4096 512 1 none 332 4096 0B Throwing these side-by-side do make me also curious if there is anything that could be impacted due to the differences in ROTA, SCHED, RQ-SIZE, and RA. Thanks for testing, that's all good info. ROTA, SCHED, RQ-SIZE, and RA shouldn't affect us, that stuff should all be transparent to gfs2 and largely under the control of sysadmins. I've submitted the patch upstream and checked that it shouldn't affect stripe alignment, so if that passes review we'll get it queued up for 8.3 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (gfs2-utils bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4550 |