[SERVER-12455] Alert if dbfiles have been moved/altered/deleted Created: 23/Jan/14  Updated: 06/Dec/22  Resolved: 19/Feb/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor - P4
Reporter: Nick Pellant 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

Assigned Teams:
Storage Execution
Participants:

 Description   

A n error should be logged when the dataSize exceeds fileSize.

This would be indicative that the database files have been deleted or altered on disk. In the case of deleted, the Linux file descriptors are still open, yet the files in dbPath have been deleted.



 Comments   
Comment by Eric Milkie [ 11/Nov/16 ]

By "altered", do you mean written to by a process other than mongod? I'm not sure how we could detect that programmatically.

Comment by Nick Pellant [ 24/Oct/16 ]

Thank you, ian.whalen - I forgot about this.

Title updated, and yes scotthernandez, an alert if the files have been moved/altered/deleted makes more sense.

Comment by Ian Whalen (Inactive) [ 24/Oct/16 ]

nick can you respond to Eric's and Scott's questions?

Comment by Scott Hernandez (Inactive) [ 23/Jan/14 ]

Nick, I think you really want to get to the underlying issue, which is that the mapped files are no longer on the filesystem (in the correct location). If so, then we really need to check that they don't disappear once we've mapped them, right?

I think the sizes here are a red herring for what we really want, which is to know if the files have been moved/altered/deleted. If so, please cleanup the summary/description to be more appropriate of the feature.

Comment by Eric Milkie [ 23/Jan/14 ]

It's not clear when this error should be logged. fileSize is calculated on-the-fly when it is requested by the stats() command, so if no one is running stats(), will the problem be noticed?

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