[SERVER-4071] mongod doesn't detect file system disappearance Created: 14/Oct/11  Updated: 06/Dec/22  Resolved: 15/Nov/16

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

Type: Improvement Priority: Minor - P4
Reporter: Richard Kreuter (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Cannot Reproduce Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux (Ubuntu Maverick x86_64).


Assigned Teams:
Storage Execution
Participants:

 Description   

It appears that at least under some versions of Linux, if the file system disappears out from under mongod, the server will continue to operate to some degree, with the consequence that data might get written to the wrong locations and so probably lost later. Probably the server ought to abort in these cases, if it's possible to detect them.

Reproduction case:


#!/bin/sh
set -e
set -u

p=30000
d="`mktemp -d`"
l="`mktemp`"
pf="`mktemp`"
u=localhost:$p/test
c1='db.c.insert(

{s:"good"}

); db.c.find().forEach(printjson)'
c2='db.c.insert(

{s:"bad"}

); db.c.find().forEach(printjson)'

sudo mount -t tmpfs -o size=512M tmpfs "$d"
trap "(set +e; sudo umount -lf \"$d\")" 0
mongod --pidfilepath "$pf" --port $p --logpath "$l" --dbpath "$d" --fork
trap "(set +e; kill -TERM `cat \"$pf\"`; sudo umount -lf \"$d\")" 0
echo "Inserting some data and doing a db.c.find():"
mongo --quiet --eval "$c1" $u
echo -n "Unmounting file system under mongod... "
sudo umount -lf "$d"
trap "(set +e; kill -TERM `cat \"$pf\"`" 0
echo "done."
echo "Testing consequences of another insert:"
mongo --quiet --eval "$c2" $u

  1. Uncomment for cleanup.
  2. rm -r "$l" "$d"


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

Can no longer reproduce this issue.

Comment by Richard Kreuter (Inactive) [ 15/Oct/11 ]

No journaling. The reproduction case above leaves no files behind.

Comment by Eliot Horowitz (Inactive) [ 15/Oct/11 ]

Is this with journalling?

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