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

xfsprogs 5.19 changed the log size, making /boot too small

Details

    • Critical
    • sst_image_builder
    • ssg_front_door
    • False
    • Hide

      None

      Show
      None
    • Unspecified
    • Approved Exception
    • Bug Fix
    • Hide
      .The new version of `xfsprogs` no longer shrinks the size of `/boot`

      Previously, the `xfsprogs` package with the 5.19 version in the RHEL 9.3 caused the size of `/boot` to shrink. As a consequence, it caused a difference in the available space on the `/boot` partition, if compared to the RHEL 9.2 version. This fix increases the `/boot` partition to 600 MiB for all images, instead of 500 MiB, and the `/boot` partition is no longer affected by space issues.
      Show
      .The new version of `xfsprogs` no longer shrinks the size of `/boot` Previously, the `xfsprogs` package with the 5.19 version in the RHEL 9.3 caused the size of `/boot` to shrink. As a consequence, it caused a difference in the available space on the `/boot` partition, if compared to the RHEL 9.2 version. This fix increases the `/boot` partition to 600 MiB for all images, instead of 500 MiB, and the `/boot` partition is no longer affected by space issues.
    • Done

    Description

      Description of problem:
      Image Builder is responsible for creating all RHEL cloud images. In the case of /boot, it firstly creates a 500 MiB, and then runs `mkfs.xfs -m uuid=3e199562-8a95-43c5-b90b-1cdebb99a29c -L boot`. This process is the same for both 9.2 and 9.3 images.

      However, we found a difference in the available space on the /boot partition on 9.2 and 9.3.

      9.2:

      [admin@vm ~]$ df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/sda3 495M 156M 340M 32% /boot
      [admin@vm ~]$ lsblk
      NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
      sda 8:0 0 10G 0 disk
      ├─sda3 8:3 0 500M 0 part /boot

      9.3:

      [admin@vm ~]$ df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/sda3 436M 170M 267M 39% /boot
      [admin@vm ~]$ lsblk
      NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
      sda 8:0 0 10G 0 disk
      ├─sda3 8:3 0 500M 0 part /boot

      See that /boot on 9.2 is 495M big, but on 9.3 it's 436M.


      I investigated more and discovered this:

      9.2:

      $ rpm -q xfsprogs
      xfsprogs-5.14.2-1.el9.x86_64
      $ truncate -s 500M /tmp/file
      $ mkfs.xfs /tmp/file
      meta-data=/tmp/file isize=512 agcount=4, agsize=32000 blks
      = sectsz=512 attr=2, projid32bit=1
      = crc=1 finobt=1, sparse=1, rmapbt=0
      = reflink=1 bigtime=1 inobtcount=1
      data = bsize=4096 blocks=128000, imaxpct=25
      = sunit=0 swidth=0 blks
      naming =version 2 bsize=4096 ascii-ci=0, ftype=1
      log =internal log bsize=4096 blocks=1368, version=2
      = sectsz=512 sunit=0 blks, lazy-count=1
      realtime =none extsz=4096 blocks=0, rtextents=0
      $ sudo mkdir /mnt/xfs
      $ sudo mount /tmp/file /mnt/xfs
      $ df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/vda3 495M 437M 59M 89% /boot

      9.3 (well, actually CentOS Stream 9):

      $ rpm -q xfsprogs
      xfsprogs-5.19.0-4.el9.x86_64
      $ truncate -s 500M /tmp/file
      $ mkfs.xfs /tmp/file
      meta-data=/tmp/file isize=512 agcount=4, agsize=32000 blks
      = sectsz=512 attr=2, projid32bit=1
      = crc=1 finobt=1, sparse=1, rmapbt=0
      = reflink=1 bigtime=1 inobtcount=1 nrext64=0
      data = bsize=4096 blocks=128000, imaxpct=25
      = sunit=0 swidth=0 blks
      naming =version 2 bsize=4096 ascii-ci=0, ftype=1
      log =internal log bsize=4096 blocks=16384, version=2
      = sectsz=512 sunit=0 blks, lazy-count=1
      realtime =none extsz=4096 blocks=0, rtextents=0
      $ sudo mkdir /mnt/xfs
      $ sudo mount /tmp/file /mnt/xfs
      $ df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/vda3 495M 401M 95M 81% /boot


      See that mkfs.xfs reports a different number of blocks in the log section. 9.2 shows 1368, whereas 9.3 shows 16384.

      ((16384 - 1368)*4096 B) to MiB is 58.6 MiB, which is equal to the size difference between those two df -h calls.


      I'm not sure if this is an expected change, thus reporting a bug. Note that customers might see this as a bug, because we usually don't change partitioning during a major release lifecycle. I think this leaves us with the following options:

      1) The change is reverted in xfsprogs
      2) Image Builder passes the right arguments to mkfs.xfs to revert the log size change.
      3) We make the partition bigger.

      Attachments

        Issue Links

          Activity

            People

              obudai@redhat.com Ondrej Budai
              obudai@redhat.com Ondrej Budai
              Osbuilders Bot Account Osbuilders Bot Account
              Release Test Team Release Test Team
              Eliane Pereira Eliane Pereira
              Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: