lkml.org 
[lkml]   [2005]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] cifs: handle termination of cifs oplockd kernel thread
On Sat, 30 Apr 2005, Steve French wrote:

> There is one remaining issue with mount and umount - the user space
> utilities. By the way who maintains
> them these days? Although the mount utilities allow filesystem
> specific mount and umount helpers
> to be placed in /sbin and automatically executed for the matching
> filesystem type, there are a few functions
> that belong in common code - in a system library which today have to be
> implemented in every helper
> function and of course are implemented in different ways in different
> distros and
> different tools with possibility of corruption of the /etc/mtab.

For user mounts, there should be no practical way of maintaining mtab,
especially if the users are using private namespaces (as suggested in
another thread) or if they are supposed to be able to unmount using
a non-suid generic umount.

> It
> may be that the file /etc/mtab
> does not matter and that it needs to go away and everyone needs to look
> at /proc/mounts instead, but
> in the meantime /etc/mtab can easily get out of sync with the actual
> list of mounts, although that
> usuallly does not prevent unmount from working it may be confusing.

The drawback of /proc/mounts is not showing the -oloop information.
Either it's easy to implement showing that extra information, or you'll
need a ~/.etc/mtab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-05-01 02:01    [W:0.076 / U:1.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site