Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-16736

device-mapper alignment inconsistency error shown for Stratis pool with multiple data devices when cache is initialized

    • Icon: Bug Bug
    • Resolution: Done-Errata
    • Icon: Major Major
    • rhel-9.4
    • None
    • stratisd
    • None
    • stratisd-3.6.2-1.el9
    • None
    • None
    • rhel-sst-logical-storage
    • ssg_filesystems_storage_and_HA
    • 14
    • 16
    • 5
    • QE ack, Dev ack
    • False
    • Hide

      None

      Show
      None
    • Yes
    • Red Hat Enterprise Linux
    • None
    • Bug Fix
    • Hide
      .The newly allocated sections of the data device are now properly aligned

      Previously, when a Stratis pool was expanded, it was possible to allocate the new regions of the pool. But the newly allocated regions were not correctly aligned with the previously allocated regions. Consequently, it could cause a performance degradation along with a non-zero entry in the Stratis thin pool's `alignment_offset` file in `sysfs`.
      With this update, when the pool expands, the newly allocated region of the data device is properly aligned with the previously allocated region. As a result, there is no degradation in performance and no non-zero entry in the Stratis thin pool's `alignment_offset` file in `sysfs`.
      Show
      .The newly allocated sections of the data device are now properly aligned Previously, when a Stratis pool was expanded, it was possible to allocate the new regions of the pool. But the newly allocated regions were not correctly aligned with the previously allocated regions. Consequently, it could cause a performance degradation along with a non-zero entry in the Stratis thin pool's `alignment_offset` file in `sysfs`. With this update, when the pool expands, the newly allocated region of the data device is properly aligned with the previously allocated region. As a result, there is no degradation in performance and no non-zero entry in the Stratis thin pool's `alignment_offset` file in `sysfs`.
    • Done
    • None

      What were you trying to do that didn't work?

      On a Stratis pool that has had at least one data device added to it, when a cache is initialized, a kernel warning will appear: "kernel: device-mapper: ... adding target device... caused an alignment inconsistency"

      Please provide the package NVR for which bug is seen:

      stratisd-3.6.1-1.el9

      How reproducible:

      100%

      Steps to reproduce

      1. stratis pool create spool1 /dev/nvme0n1p2
      2. stratis fs create spool1 sfs1
      3. stratis pool add-data spool1 /dev/nvme0n1p3
      4. stratis pool init-cache spool1 /dev/nvme0n1p4

      Expected results

      No kernel log messages from "device-mapper" citing an alignment inconsistency.

      Actual results

      (For the device corresponding to the "flex-thinmeta" device of the Stratis pool, shown here as "253:1": )
      kernel: device-mapper: table: 253:1: adding target device (start sect 10624 len 4160) caused an alignment inconsistency

      stratis-1-private-c6cd18cf87b0454393e526d1d9949ff5-flex-thinmeta: 0 10624 linear 253:7 0
      stratis-1-private-c6cd18cf87b0454393e526d1d9949ff5-flex-thinmeta: 10624 4160 linear 253:7 16767744

      (For the device corresponding to the "flex-thindata" device of the Stratis pool; shown here as "253:2": )
      kernel: device-mapper: table: 253:2: adding target device (start sect 15697920 len 16760832) caused an alignment inconsistency

      stratis-1-private-c6cd18cf87b0454393e526d1d9949ff5-flex-thindata: 0 15697920 linear 253:7 21248
      stratis-1-private-c6cd18cf87b0454393e526d1d9949ff5-flex-thindata: 15697920 16760832 linear 253:7 16776064

              stratis-team stratis-team
              bgurney@redhat.com Bryan Gurney
              stratis-team stratis-team
              Filip Suba Filip Suba
              Apurva Bhide Apurva Bhide
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: