Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-12785

DOM2: dynamic DoM component size as MDT becomes full

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Lustre 2.14.0
    • Labels:
    • Rank (Obsolete):
      9223372036854775807

      Description

      As the MDT becomes full it makes sense to reduce the size or completely remove DOM components from the layout if created from default directory or root filesystem layout. i think a reasonable heuristic would be that if the percentage of free inodes is larger than the percentage of free space, the size of the DoM component can be increased (up to the mdt.*.dom_stripesize maximum). If the percentage of free inodes is smaller than the percentage of free space, or if the MDT is within configurable threshold (e.g. mdt.*.dom_threshold=10%) of being full, the DoM component size should be cut in half, and within 1/2 of mdt.*.dom_threshold the DoM component should be removed (or similar, see more complex options below).

      Note that the DoM component size must be a multiple of LOV_MIN_STRIPE_SIZE (64KiB) so it will not be possible to exactly match the inode ratio with the blocks ratio, but it makes sense to keep them relatively well balanced by default.

      It could be proposed to have a policy that each 1/4 reduction in free space below mdt.*.dom_threshold should reduce the DoM component size by 1/2 until it is below the 64KiB minimum component size. That would ensure that the ldiskfs MDT+DoM filesystem is not completely filled with DoM data when it is close to being filled. This is most critical for ldiskfs filesystems, since ZFS has dynamic inode allocation, but can still help ZFS to avoid being totally filled by DoM data. This should also be helped by LU-12624 to balance DNE directory allocations across MDTs, but that is only a coarse-grained balance and will not prevent MDTs filling with DoM data too quickly.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              tappro Mikhail Pershin
              Reporter:
              tappro Mikhail Pershin
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: