If EMS datastore is on /mnt/datastore, after the command "umount -l /mnt/datastore" is run, EMS server can still write to the store.

 

When umount is run with "-l (lazy)" option to umount EMS datastore drive, it is expected that EMS server can still write to the datastore. The "lazy" option means that the mounted device is hidden but application can still access it.

As an application, EMS server accesses disk by file descriptors.

Before "umount -l /mnt/datastore" is run, "lsof -nP -p <ems_pid>" shows the following:
===
tibemsd 14814 user   18uW     REG               0,49     1536   568897 /mnt/datastore/sync-msgs.db (host:/mnt/datastore)
===

After "umount -l /mnt/datastore" is run, "lsof -nP -p <ems_pid>" shows the following:
===
tibemsd 14814 user   18uW     REG               0,49     1536   568897 /datastore/sync-msgs.db
===

File descriptors still point to files.

If EMS server is restarted, the server is no longer able to access the stores.

Please refer to https://man7.org/linux/man-pages/man8/umount.8.html.
---
-l, --lazy Lazy unmount. Detach the filesystem from the file hierarchy now, and clean up all references to this filesystem as soon as it is not busy anymore.
A system reboot would be expected in near future if you’re going to use this option for network filesystem or local filesystem with submounts. The recommended use-case for umount -l is to prevent hangs on shutdown due to an unreachable network share where a normal umount will hang due to a downed server or a network partition. Remounts of the share will not be possible.
----
There are below discussion about "umount -l" on Internet.

https://serverfault.com/questions/1101277/how-does-a-lazy-unmount-actually-work
https://superuser.com/questions/412109/lazy-umount-or-unmounting-a-busy-disk-in-linux

 

After "umount -l" is run on the EMS datastore drive, EMS server can still write to the datastore.