ISSUE SUMMARY
MongoDB installations on some Linux systems running on VMWare may see corruption in namespace files.
MongoDB uses namespace (.ns) files to store database and collection metadata, and requires initial zeroing of these .ns files upon creation. A request to the operating system to zero a .ns file may fail to completely zero the file, leaving the previous contents of some disk locations exposed as part of the .ns file. This incomplete zeroing yields a corrupt .ns file, and may affect MongoDB in various ways.
Only .ns files created on systems running the following configuration are affected by this issue:
- certain 3.x Linux kernels, including Ubuntu 12.x, 14.x, and Fedora 20; and
- VMWare platform, including VMWare ESXi, Fusion, and Workstation; and
- virtual SCSI disks managed by LVM
See the bug report on Launchpad for more information.
USER IMPACT
Symptoms that have been observed include:
- failures of various operations that require enumerating namespaces, such as db.stats(), db.repairDatabase(), db.dropDatabase(), and others
- operations such as the above that don’t fail may report nonsense database names
- failure of mongod to start
These failures may be accompanied by logged error messages such as:
- exception: assertion src/mongo/db/catalog/database.cpp:472
- Assertion failure _name == nsToDatabaseSubstring( ns ) src/mongo/db/catalog/database.cpp 472
- exception: nsToDatabase: db too long
- Fatal Assertion 16253
- ERROR: Uncaught std::exception: basic_string::substr, terminating
- Error messages like: {"ok" : 0, "errmsg" : "missing ns: ..."}
Additional symptoms may be possible depending on the exact nature of the left-over data in the .ns file.
WORKAROUNDS
There are no workarounds for affected systems. For new installations using the above setup users may either apply a vendor-supplied patch to their Linux kernel, use IDE/SATA disks instead of SCSI, or avoid the use of LVM.
AFFECTED VERSIONS
MongoDB production releases up to 2.6.4 are affected by this issue.
FIX VERSION
MongoDB versions 2.6.5 and 2.4.12 include a workaround for this issue. This workaround does not fix .ns files that are already corrupted.
RESOLUTION DETAILS
Make mongod manually allocate and zero .ns files.
Original description
Certain versions of Linux may under some conditions use SCSI WRITE SAME to implement the requirement to zero a file on initial allocation. However, certain platforms do not properly implement WRITE SAME. The result is that the initial zeroing of a file may be unreliable on those platforms, causing potentially fatal corruption in the .ns file, which depends on the initial zeroing of the file to initialize the hash table. As a defensive measure mongod could explicitly zero the .ns files on creation.
- is duplicated by
-
SERVER-14137 db stats
- Closed