Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-15369

explicitly zero .ns files on creation

    • Type: Icon: Improvement Improvement
    • Resolution: Done
    • Priority: Icon: Critical - P2 Critical - P2
    • 2.4.12, 2.6.5, 2.7.7
    • Affects Version/s: None
    • Component/s: Storage
    • None
    • Fully Compatible
    • 0

      Issue Status as of Oct 03, 2014

      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.

      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.

      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.

      MongoDB production releases up to 2.6.4 are affected by this issue.

      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.

      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.

            mathias@mongodb.com Mathias Stearn
            bruce.lucas@mongodb.com Bruce Lucas (Inactive)
            0 Vote for this issue
            10 Start watching this issue