{
  "status": "shipping",
  "advantages": [
    {
      "text": "Reservation, weight and limit provide separate controls for minimum service, relative sharing and a service ceiling.",
      "citationIds": [
        "ceph-osd"
      ]
    }
  ],
  "limitations": [
    {
      "text": "An OSD shard's queue does not coordinate its scheduling state with other shards, and dequeued operations are outside that queue's control.",
      "citationIds": [
        "ceph-osd"
      ]
    },
    {
      "text": "The original overload policy can starve a zero-reservation VM even when its weight is positive.",
      "citationIds": [
        "mclock-paper"
      ]
    }
  ],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "updated": "2026-11-03",
  "slug": "mclock",
  "term": "mClock",
  "aliases": [
    "mClock I/O scheduler"
  ],
  "definition": "mClock is an I/O scheduling algorithm that combines minimum reservations, proportional weights and maximum limits.",
  "note": "Requests receive separate reservation, limit and share tags; dispatch alternates between satisfying constraints and proportional service. Admission control must establish that reservations fit available capacity. [mclock-paper]\n\nIf throughput falls below the aggregate reservation, the original paper allocates service in proportion to reservations; a zero-reservation VM can starve despite its positive weight. Admission-time feasibility is therefore not an unconditional guarantee under later capacity loss. [mclock-paper]\n\nWeight-based allocation includes service already received under reservation; a reservation is not a bonus added to a separate weighted entitlement. [ceph-osd]\n\nCeph Reef's profiles configure service classes for client I/O, background recovery and background best-effort work. Their capacity-dependent settings are not per-application latency promises. [ceph-profile]\n\nThe paper's distributed extension, dmClock, carries service-accounting information with requests. Independent local queues should not be mistaken for that cluster-wide accounting. [mclock-paper] Ceph documents separate queues per OSD shard and loss of scheduler control after transfer to the operation sequencer. [ceph-osd]\n\nThe original prototype batches nearby requests to improve locality, which can delay reservation service over short intervals. Its throughput reservation is not a deadline for every individual completion. [mclock-paper]\n\nThe paper's Little's-law sizing example concerns average latency, not p99 or individual completion deadlines; the linked fluid arithmetic does not simulate request completion times. [mclock-paper]",
  "related": [
    "io-scheduler",
    "slowdown-fairness",
    "queue-depth"
  ],
  "citations": [
    {
      "id": "mclock-paper",
      "title": "Gulati, Merchant and Varman. mClock: Handling Throughput Variability for Hypervisor IO Scheduling. OSDI 2010, sections 2.1, 3 and 3.2.",
      "url": "https://www.usenix.org/events/osdi10/tech/full_papers/Gulati.pdf",
      "accessed": "2026-11-03"
    },
    {
      "id": "ceph-osd",
      "title": "Ceph Reef: OSD Config Reference, Subtleties of mClock and Caveats",
      "url": "https://docs.ceph.com/en/reef/rados/configuration/osd-config-ref/#qos-based-on-mclock",
      "accessed": "2026-11-03"
    },
    {
      "id": "ceph-profile",
      "title": "Ceph Reef: mClock Config Reference, client types and profiles",
      "url": "https://docs.ceph.com/en/reef/rados/configuration/mclock-config-ref/",
      "accessed": "2026-11-03"
    },
    {
      "id": "hesela",
      "title": "Hesela: Sharing an SSD: who pays for the slowdown?",
      "url": "https://hesela.com/analyses/ssd-fairness-shared-queues/",
      "accessed": "2026-10-31"
    }
  ],
  "provenance": [
    "Algorithm publication and version-scoped Ceph documentation; not a benchmark of a contemporary SSD.",
    "The linked two-client fluid example is Hesela arithmetic, not a request-level mClock or dmClock implementation."
  ]
}