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

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

    • Critical
    • sst_image_builder
    • ssg_front_door
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • Approved Exception
    • None
    • None
    • 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
    • None

      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.

            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

              Created:
              Updated:
              Resolved: