<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
FWIW - <br>
<br>
I looked at Tigran's implementation, and it was a decent job - the algorithm
used was to install a filesystem to handle request to the unmounted file
system by returning an error. &nbsp;He then looped through the task list, removing
file descriptors that references the subject file system, removing working
directory references and removing mmaps. &nbsp;At the end, the file system should
have the correct reference count for unmounting. &nbsp;The main issue is that
I was unclear if new request could occur after the list was walked, potentially
causing the unmount not to occur. &nbsp;The other issue is scalability with large
numbers of tasks, perhaps.<br>
<br>
My implementation is a bottom up one, with the unmount process first "walling
off" system calls that could create new references. &nbsp;The mount point is marked
as fumount pending, and subsequent syscalls that would use a file descriptor
would have the fget fail with a NULL file object, leading the calls to return
-EBADF. &nbsp;If the syscall used a file name string, then the namei lookups would
fail, generally returning -ENXIO. &nbsp;Then there is a pause, the intention of
which is to allow contexts in the kernel to clear out - such a pending reads.
&nbsp;Following that, the file objects are marked as subject to fumount, and then
outstanding references to the file objects are cancelled - locks are removed
and mmaps deleted. &nbsp;If there remain outstanding file references, the file
object is cloned, leaving the old object with null operations. Following
that, only a close will succeed. &nbsp;The cloned object is taken over by the
umount process, and closed however many times required to drive the reference
count to 0. &nbsp;Once the super block file list is emptied, the mount reference
count is checked. &nbsp;If still not at the magic number, then the task list is
walked, looking for cwd entries that are subordinate to the fs mount point.
&nbsp;If found, the task is given a NULL cwd. &nbsp;Various parts of the lookup routines
have had error handling added so that the NULL cwd entry does not cause problems.
&nbsp;After that, the mount ref count is checked again. &nbsp;If still not the magic
number, then an arbitrary mntput is done, potentailly losing resources. &nbsp;However,
that has not happened in our testing. &nbsp;It's complicated, but seems solid
after our testing. &nbsp;There are a couple of rules that the sysadmin should
follow: &nbsp;Any nfs export stuff subordinate to the mount point should be unexported
before fumount - I can't find non-process related kernel references, and
NFS is the only entity that might pose a problem there - it's stateless,
so the problem is transitory, but nonetheless, I recommend removing the export.
The second rule is that if the mount point has subordinate mounts, these
must be removed first by the admin - I chose not to allow the unmount to
automatically recurse. &nbsp;Finally, the filesystem cannot be the root filesystem,
although that is arbitrary as far as the code is concerned - fumount checks
for it and doesn't do the forced unmount if the subject is /<br>
<br>
This was messy and took a while to get right, primarily due to the Linux's
ill-defined locking paradigm. &nbsp;Lists of objects are locked, while the objects
themselves only have reference counts. &nbsp;I was unaware of Tigran's implementation
at the start of the project. &nbsp;Looking at it, there are some things I really
like, so a combination of the two might be the best implementation.<br>
<br>
Mark Huth<br>
<br>
Carl-Daniel Hailfinger wrote:<br>
<blockquote type="cite" cite="mid3EA7B0D1.8090604@gmx.net">
  <pre wrap="">[CC:ed Mark Huth and Tigran Aivazian]

Christoph Hellwig wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">   4.10 Force unmount (2) 2 Experimental Availability Core
   4.10 Description: 

   CGL shall support forced unmounting of a filesystem.
     * The  unmount should work even if there are open files or processes
       in the file system.
     * Pending  requests  should  be  ended with an error return when the
       file system is unmounted.


This is very hard to get right.  What the expermintel implementation
you're referring to?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
IIRC, Mark Huth from MontaVista and Tigran Aivazian from Veritas both
developed such an implementation independently of each other.
Maybe they can offer some insight.

Regards,
Carl-Daniel



  </pre>
</blockquote>
<br>
</body>
</html>