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.)

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

+|-f [cfgGn] f by itself clarifies how path name arguments are to be interpreted. When followed by c, f, g, G, or n in any combination it specifies that the listing of kernel file structure information is to be enabled (`+') or inhibited (`-'). Normally a path name argument is taken to be a file system name if it matches a mounted-on directory name reported by mount(8), or if it represents a block device, named in the mount output and associated with a mounted directory name. When +f is specified, all path name arguments will be taken to be file system names, and lsof will complain if any are not. This can be useful, for example, when the file system name (mounted-on device) isn't a block device. This happens for some CD-ROM file systems. When -f is specified, all path name arguments will be taken to be simple files. Thus, for example, the ``-f /'' arguments direct lsof to search for open files with a `/' path name, not all open files in the `/' (root) file system. Be careful to make sure +f is properly terminated and isn't followed by a character (e.g., of the file or file system name) that might be taken as a parameter. For example, use ``--'' after +f as in this example. $ lsof +f -- /file/system/name The listing of information from kernel file structures, requested with the +f [cfgGn] option form, is normally inhibited, and is not available for some dialects - e.g., /proc-based Linux. When the prefix to f is a plus sign (`+'), these characters request file structure information: c file structure use count f file structure address g file flag abbreviations G file flags in hexadecimal n file structure node address When the prefix is minus (`-') the same characters disable the listing of the indicated values. File structure addresses, use counts, flags, and node addresses may be used to detect more readily identical files inherited by child processes and identical files in use by different processes. Lsof column output can be sorted by output columns holding the values and listed to identify identical file use, or lsof field output can be parsed by an AWK or Perl post-filter script, or by a C program.

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...