[SERVER-55486] Design new integration test facility to use Device-mapper to reproduce disk outage Created: 24/Mar/21  Updated: 06/Dec/22  Resolved: 23/Apr/21

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

Type: Task Priority: Major - P3
Reporter: Andrew Shuvalov (Inactive) Assignee: [DO NOT USE] Backlog - Sharding NYC
Resolution: Won't Fix Votes: 0
Labels: sharding-product-sync
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-55487 Use new device mapper testing facilit... Closed
Assigned Teams:
Sharding NYC
Participants:

 Description   

Background

We have a HELP ticket scenario when a faulty disk made all disk I/O to be blocked for indefinite time, which caused the process to enter the uninterruptible sleep state. The main culprit of this state is that when SIGKILL is issued the process is not killed because it's blocked on a syscall. The user killed the primary mongod server with -9 but it was not killed. After 13 minutes after SIGKILL, the user had to shut down the Amazon EC2 instance to break down hung sessions from multiple mongos proxies to the faulty primary. This happened with v4.0.

More background on why `kill -9` will never kill the process in the uninterruptible sleep state:
https://askubuntu.com/questions/59811/kill-pid-not-really-killing-the-process-why

Various tricks people use to simulate the uninterruptible sleep state:
https://unix.stackexchange.com/questions/134888/simulate-an-unkillable-process-in-d-state

More background on why kernel prevents killing process in this kind of state:
https://stackoverflow.com/questions/223644/what-is-an-uninterruptible-process

and LWN article: https://lwn.net/Articles/288056/

Implementation details

The process of setting the device mapper has multiple steps:
1. Create a file and map the file to a new loopback device using `losetup`
2. Use `dmsetup` to map the loopback device to a device mapper device
3. Use `mkfs.ext4` to format it
4. Create the directory structure for replica set
5. Mount one of the replicas (rs1) data directory to the mapper device
6. Use `dmsetup suspend` to simulate disk outage

This procedure was already done manually and fully reproduced the production outage.

Not the same as network proxy

Please note that we already have mongobridge to simulate network errors, however this is not the same. The mongo bridge cannot make the outage in the mongod, it can only make the client to think that mongod has an outage, which is very different from the scenario in HELP ticket.



 Comments   
Comment by Andrew Shuvalov (Inactive) [ 24/Mar/21 ]

The trick is that device mapper can be suspended, while loopback device cannot. But device mapper cannot map directly from file. So the topology is:

file -> loopback device -> device mapper

Comment by Andrew Shuvalov (Inactive) [ 24/Mar/21 ]

References: this is related to HELP-22913.

The document on mongo bridge is:
https://docs.google.com/document/d/1554KDAnJ-i6EQDDhwGuDulP-uFTJESzL3C4dafjqZvk/edit#heading=h.qsuqufq21x78

Generated at Thu Feb 08 05:36:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.