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

Cannot start WT with dbpath on an NFS mount

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 3.0.0
    • Component/s: Storage, WiredTiger
    • Labels:
    • Fully Compatible
    • ALL
    • Hide

      1. Create an NFS mount point /data-nfs
      2. ./bin/mongod --dbpath /data-nfs/db --logpath ./server.log --fork --syncdelay 14400 --storageEngine=wiredTiger --bind_ip 127.0.0.1

      Show
      1. Create an NFS mount point /data-nfs 2. ./bin/mongod --dbpath /data-nfs/db --logpath ./server.log --fork --syncdelay 14400 --storageEngine=wiredTiger --bind_ip 127.0.0.1

      Problem

      Have an NFS mount on a Linux machine

      10.5.0.132:/vol/harpoon  /data-nfs nfs lock,rw,bg,hard,nointr,rsize=32768,wsize=32768,suid,tcp,timeo=600,noatime  0 0
      

      The process running mongodb can create files etc. just ok. However, on startup get the following errors in the log

      2015-03-05T15:30:01.307-0800 I CONTROL  [initandlisten] MongoDB starting : pid=29103 port=27017 dbpath=/data-nfs/db 64-bit host=bismark
      2015-03-05T15:30:01.307-0800 I CONTROL  [initandlisten] db version v3.0.0
      2015-03-05T15:30:01.307-0800 I CONTROL  [initandlisten] git version: a841fd6394365954886924a35076691b4d149168
      2015-03-05T15:30:01.307-0800 I CONTROL  [initandlisten] build info: Linux build15.nj1.10gen.cc 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Jan 3 21:39:27 UTC 2014 x86_64 BOOST_LIB_VERSION=1_49
      2015-03-05T15:30:01.307-0800 I CONTROL  [initandlisten] allocator: tcmalloc
      2015-03-05T15:30:01.307-0800 I CONTROL  [initandlisten] options: { net: { bindIp: "127.0.0.1" }, processManagement: { fork: true }, storage: { dbPath: "/data-nfs/db", engine: "wiredTiger", syncPeriodSecs:
       14400.0 }, systemLog: { destination: "file", path: "/data3/logs/db/server.log" } }
      2015-03-05T15:30:01.338-0800 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=15G,session_max=20000,eviction=(threads_max=4),statistics=(fast),log=(enabled=true,archive=true,path=journ
      al,compressor=snappy),checkpoint=(wait=14400,log_size=2GB),statistics_log=(wait=0),
      2015-03-05T15:30:01.339-0800 E STORAGE  [initandlisten] WiredTiger (16) [1425598201:339229][29103:0x7ffff7fddb80], wiredtiger_open: WiredTiger database is already being managed by another process: Device 
      or resource busy
      2015-03-05T15:30:01.339-0800 I -        [initandlisten] Assertion: 28595:16: Device or resource busy
      2015-03-05T15:30:01.340-0800 I STORAGE  [initandlisten] exception in initAndListen: 28595 16: Device or resource busy, terminating
      2015-03-05T15:30:01.340-0800 I CONTROL  [initandlisten] dbexit:  rc: 100
      

      This comes from https://github.com/mongodb/mongo/blob/v3.0/src/third_party/wiredtiger/src/conn/conn_api.c#L1164

      	WT_ERR(__wt_open(session, WT_SINGLETHREAD, 1, 0, 0, &conn->lock_fh));
      
      	/*
      	 * Lock a byte of the file: if we don't get the lock, some other process
      	 * is holding it, we're done.  The file may be zero-length, and that's
      	 * OK, the underlying call supports locking past the end-of-file.
      	 */
      	if (__wt_bytelock(conn->lock_fh, (wt_off_t)0, 1) != 0)
      		WT_ERR_MSG(session, EBUSY,
      		    "WiredTiger database is already being managed by another "
      		    "process");
      

      Several file had been created in this directory before the process terminated

      ls -l /data-nfs/db/
      total 4
      drwxr-xr-x 2 nobody nogroup 4096 Dec 31  1969 journal
      -rwxr-xr-x 1 nobody nogroup    0 Dec 31  1969 mongod.lock
      -rw-r--r-- 1 nobody nogroup    0 Dec 31  1969 WiredTiger.lock
      

            Assignee:
            Unassigned Unassigned
            Reporter:
            alvin Alvin Richards (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: