Uploaded image for project: 'Facter'
  1. Facter
  2. FACT-1814

Mountpoints Fact available space does not accurately reflect disk usage

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Accepted
    • Priority: Normal
    • Resolution: Unresolved
    • Affects Version/s: FACT 3.6.5
    • Fix Version/s: FACT 4.0.0
    • Component/s: None
    • Labels:
    • Template:
    • Team:
      Platform OS
    • CS Priority:
      Minor
    • CS Frequency:
      2 - 5-25% of Customers
    • CS Severity:
      2 - Annoyance
    • CS Business Value:
      3 - $$$$
    • CS Impact:
      Hide
      In a situation where a customer is relying on facter to determine if there is space to install something this could be frustrating.

      That said there is are known discrepancies between `statfs` which facter uses and df which the customer is using in this case.
      Show
      In a situation where a customer is relying on facter to determine if there is space to install something this could be frustrating. That said there is are known discrepancies between `statfs` which facter uses and df which the customer is using in this case.
    • QA Risk Assessment:
      Needs Assessment

      Description

      PE 2017.2.2 ( facter 3.6.5) RHEL 6.8

      The customer is using mountpoints.(parition).available_bytes in conditional logic to determine if software should be installed on a system during Puppet Runs.

      In testing it appears that there is around a 400mb discrepancy between what is reported by facter as available, and what is actually available, which is backed up by df -h.

      In a test where by continual facter outputs and df outputs where collected during a large file transfer to the target partition, both facter and df -h tracked upwards in consumed disk space, but never agreed with each other, full attachments below, however a snippet can be seen here:

      ----facter---- 2.39 GiB 58.62%
      ----system----
      Filesystem                 Type  Size  Used Avail Use% Mounted on
      /dev/mapper/vg_root-lv_var ext4  5.8G  3.4G  2.1G  62% /var
      ----facter---- 2.39 GiB 58.62%
      ----system----
      Filesystem                 Type  Size  Used Avail Use% Mounted on
      /dev/mapper/vg_root-lv_var ext4  5.8G  3.4G  2.1G  62% /var
      ----facter---- 846790656 773.65 MiB 87.52%
      ----system----
      Filesystem                 Type  Size  Used Avail Use% Mounted on
      /dev/mapper/vg_root-lv_var ext4  5.8G  5.1G  431M  93% /var
      ----facter---- 415592448 396.34 MiB 93.30%
      ----system----
      Filesystem                 Type  Size  Used Avail Use% Mounted on
      /dev/mapper/vg_root-lv_var ext4  5.8G  5.4G   90M  99% /var
      ----facter---- 415592448 396.34 MiB 93.30%
      ----system----
      Filesystem                 Type  Size  Used Avail Use% Mounted on
      /dev/mapper/vg_root-lv_var ext4  5.8G  5.4G   90M  99% /var
      ----facter---- 415592448 396.34 MiB 93.30%
      ----system----
      Filesystem                 Type  Size  Used Avail Use% Mounted on
      /dev/mapper/vg_root-lv_var ext4  5.8G  5.4G   90M  99% /var
      ----facter---- 421269504 401.75 MiB 93.21%
      ----system----
      Filesystem                 Type  Size  Used Avail Use% Mounted on
      /dev/mapper/vg_root-lv_var ext4  5.8G  5.4G   95M  99% /var
      ----facter---- 421269504 401.75 MiB 93.21%
      ----system----
      Filesystem                 Type  Size  Used Avail Use% Mounted on
      /dev/mapper/vg_root-lv_var ext4  5.8G  5.4G   95M  99% /var
      

      It could be that facter is failing to take into consideration the blocksize for the partition, in which case i have provided the output below:

      blockdev --getbsz /dev/mapper/vg_root-lv_var 4096

      Used space seems also to agree where available does not:

      used => "5.39 GiB", for facter and 5.4G in df -h

      EDIT: Add an "unprivileged_free_space" element to the mountpoints structured fact that keys off of b_avail. This value will reflect what is see in df output, which more closely matches what users expect to see.

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            martin.ewings Marty Ewings
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Dates

              Created:
              Updated:

                Zendesk Support