[SERVER-10556] Gracefully handle filesystem becoming read-only in a running mongod process Created: 17/Aug/13  Updated: 06/Dec/22  Resolved: 04/Mar/19

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: 2.5.1
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Andre de Frere Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Storage Execution
Participants:

 Description   

Currently, in the case a filesystem goes read only will crash with a "can't take write lock" message.

It would be preferable for the following:

  1. Mongod should continuously monitor the state of the file system where /data is located for being in read-only state
  2. When read-only state is detected mongod should immediately step down as a master and exit gracefully
  3. If mongod is started while the file system is in read-only state mongod should block and wait until the file system becomes writable; in this blocked state it should be seen as "recovering" by its peers much like the state when mongod is replaying journal files after restart.


 Comments   
Comment by Adam Midvidy [ 01/Mar/16 ]

SERVER-593 is now tracking just the ability to run MongoD on a read-only file system. This ticket has been reopened to track gracefully handling the transition from a writable to read-only dbpath in a running MongoD.

Comment by Eliot Horowitz (Inactive) [ 17/Aug/13 ]

SERVER-593

Generated at Thu Feb 08 03:23:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.