Is umount -l dangerous?

I had a umount busy issue, that the usual fuser -mk did not solve, I did a umount -l and was able to unmount the device, I then got in trouble by the storage team staff:

Here was a snippet of their response:

Using "umount -l" is a potentially dangerous act.
The command combination for a lazy unmount "umount -l" has been outlawed in the past by the storage team.
It has caused outages on filers (they had to reboot)

I have never had the issue myself in the past with the command, and was wondering if anyone had any personal experience on this issue?

Thks.

Well, if you can't track down what's keeping it open with fuser, how will a lazy unmount help? It doesn't force anything, just waits. It doesn't stop anything from opening either, so it could well wait forever. If the filesystem is having actual problems, the system could be stuck forever waiting for operations to complete that will simply never complete with no way to cancel the unmount short of rebooting and hoping the filesystem isn't left in an unusable state.

It doesn't wait, it pretty much says "OK, Lets just drop the connection" and allows the FS to sort it out later.

From the manual:

-l 
    Lazy unmount. Detach the filesystem from the filesystem hierarchy 
    now, and cleanup all references to the filesystem as soon as 
    it is not busy anymore. (Requires kernel 2.4.11 or later.)

So the filesystem is not "really" completely unmounted, it is in a state waiting for the processes using the filesystem to end so the filesystem can be cleaned up.

I would not recommend this. It is better to find the processes using the filesystem (with lsof, for example) and them manually kill the processes and then unmount. I would not want my server and filesystem to be in such a wait state of uncertainty.

---------- Post updated at 19:11 ---------- Previous update was at 19:00 ----------

Not really..... it does not drop the busy connections, it waits, and then cleans up, after the busy processes terminate.

---------- Post updated at 19:20 ---------- Previous update was at 19:11 ----------

FYI, FWIW from lsof manual:

Sorry, I did not mean the process connection. I meant the file system mount status to users was "offline" and the cleanup would occur later. It was not meant to be horribly accurate but give a very high level overview of "Do now, clean later"

That's not accurate either. I went and tested it before spouting off, you know...

Users who have open directories are not stopped from traversing them, opening files in them, writing things in files, or perhaps even creating files. In other words, a lazy unmount doesn't do anything at all to the filesystem until it's free -- it just fakes it. That is, it denies access to a mounted filesystem until everyone closes all references to it. That's pretty much the worst of both worlds: It's mounted, so you can't do a thing to the devices, but it acts like its offline and denies everyone access. If the administration couldn't quickly find whatever reference is plugging up the unmount, they really would have to reboot the machine, it's either that or send the people who need to use that partition home for the day.

It wouldn't be so bad if there was a way to cancel a lazy unmount...

Interesting. That was not at all how it was explained to me. I did not have a chance to test it at the time I responded, but I'll give it a go. I have only been using it for NFS mounts when the remote machine has gone offline and the local machine has not "let go".

There's a special umount option just for forcing nfs partitions if your admins will let you use -f.

The issue was when the -f option was also not forcing a quit. I have only ever really used umount -l for the above. I also do think, especially with what you have said, that it probably is very dangerous.

Doesn't mean that it will implode your machine having used it, but it sure as hell could present problems.