Determine and implement the correct fallback policy for getAvailableDiskSpaceBytes when filesystem stats cannot be collected

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage Execution
    • ALL
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Goal / Objective

      Change the I/O-error fallback in getAvailableDiskSpaceBytes from INT64_MAX to appropriate fallback behavior so that callers which gate writes on available disk space — specifically ensureSufficientDiskSpaceForSpilling — fail safe when the filesystem cannot be queried, rather than silently proceeding.

      Context & Background

      getAvailableDiskSpaceBytes (disk_space_util.cpp) is called by two distinct consumers
        with opposing safe-default requirements:

      1. DiskSpaceMonitor — uses disk space readings to decide whether to fire registered low-disk-space handler actions.
        For this caller, returning INT64_MAX on failure is correct: it prevents spurious handler invocations when stats are temporarily unavailable.
      2. ensureSufficientDiskSpaceForSpilling — gates spill writes on whether sufficient disk space is available.
        For this caller, returning INT64_MAX on failure is unsafe: it causes the check available < minRequired to evaluate to false, unconditionally allowing spilling even when the OS cannot confirm that enough disk space exists. If the disk is actually full or the path is invalid, this silently allows writes to proceed.

      The current comment in the code — "We don't want callers to take any action if we can't collect stats" — was written in the context of DiskSpaceMonitor and does not reflect the correct policy for the spilling use case (this should be changed).

        Acceptance Criteria

        - getAvailableDiskSpaceBytes and/or getAvailableDiskSpaceBytesInDbPath return a value that causes ensureSufficientDiskSpaceForSpilling to fail (return OutOfDiskSpace) when the underlying boost::filesystem::space() call sets an error code.
        - DiskSpaceMonitor behavior is preserved: it does not trigger registered actions when disk stats cannot becollected.
        - One of the following approaches is taken (choose the least invasive):
          - Option A (preferred): Split the fallback: introduce a separate getAvailableDiskSpaceBytesForSpilling (or equivalent) that returns 0 on error, and update ensureSufficientDiskSpaceForSpilling to call it.
          - Option B: Pass a caller-supplied fallback value into getAvailableDiskSpaceBytes so each consumer controls its own error policy.
          - Option C: Return 0 from getAvailableDiskSpaceBytes on error, and update DiskSpaceMonitor to explicitly treat 0 as "stats unavailable, skip action."
        - The unit test EnsureSufficientDiskSpaceForSpillingTest.UnknownDiskSpaceAllowsSpilling in
        spill_util_test.cpp is updated to assert OutOfDiskSpace (not OK) when INT64_MAX is simulated, reflecting the corrected policy.
        - A corresponding DiskSpaceMonitor test confirms it does not fire handlers when stats are unavailable.

        Constraints & Out of Scope

        - No change to the spilling threshold values or internalQuerySpillingMinAvailableDiskSpaceBytes.
        - No change to the public signature of ensureSufficientDiskSpaceForSpilling.
        - No redesign of the DiskSpaceMonitor action registration API.
        - Do not add new server parameters.

      Testing Instructions

      1. Build and run spill_util_test: confirm the updated UnknownDiskSpaceAllowsSpilling test now expects OutOfDiskSpace.
      2. Build and run db_storage_test (which includes disk_space_monitor_test): confirm no DiskSpaceMonitor tests regress.
      3. Manually verify by activating simulateAvailableDiskSpace with bytes: 0 against a running mongod and
          confirming that a query that would spill returns OutOfDiskSpace rather than silently proceeding.

            Assignee:
            Unassigned
            Reporter:
            Stephanie Eristoff
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: