forced umount

[Bernd Schubert-5]

Hello Miklos,

fuse presently kills connections when the -f umount flag is given, even if
there are still open filedescriptors. At least debian and ubuntu umount
scripts add the force flag by default on system halt/reboot. Access
to /usr, /etc and so will then end in "transport endpoint is not connected"
and further run level scripts to finish the system shutdown can't run and so
the system deadlocks.

Could you please consinder the patch below?


Signed-off-by: Bernd Schubert <bs@...>


diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index 3141690..5c3059c 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -258,7 +258,9 @@ struct inode *fuse_iget(struct super_block *sb, u64
nodeid,
 
 static void fuse_umount_begin(struct super_block *sb)
 {
- fuse_abort_conn(get_fuse_conn_super(sb));
+ /* kill the connection, but only if we can get rid of all inodes */
+ if (!invalidate_inodes(sb))
+ fuse_abort_conn(get_fuse_conn_super(sb));
 }
 
 static void fuse_send_destroy(struct fuse_conn *fc)


Thanks,
Bernd

--
Bernd Schubert
Q-Leap Networks GmbH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Allen Pulsifer-3]

> fuse presently kills connections when the -f umount flag is
> given, even if
> there are still open filedescriptors. At least debian and
> ubuntu umount
> scripts add the force flag by default on system halt/reboot. Access
> to /usr, /etc and so will then end in "transport endpoint is
> not connected"
> and further run level scripts to finish the system shutdown
> can't run and so
> the system deadlocks.
>
> Could you please consinder the patch below?

umount -f is a valuable feature.  It would be a big loss if umount -f no
longer worked with FUSE.

The place to make changes is in your shutdown scripts.  Either change the
shutdown order, so the file system is not dismounted when it is still
needed, or remove the -f flag (if you think that will solve the problem).


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Bernd Schubert-5]

On Tuesday 22 July 2008 18:34:20 Allen Pulsifer wrote:

> > fuse presently kills connections when the -f umount flag is
> > given, even if
> > there are still open filedescriptors. At least debian and
> > ubuntu umount
> > scripts add the force flag by default on system halt/reboot. Access
> > to /usr, /etc and so will then end in "transport endpoint is
> > not connected"
> > and further run level scripts to finish the system shutdown
> > can't run and so
> > the system deadlocks.
> >
> > Could you please consinder the patch below?
>
> umount -f is a valuable feature.  It would be a big loss if umount -f no
> longer worked with FUSE.

But it does nothing then just killing the binary (close the filedescriptor
to /dev/fuse) - which is also the reason why it causes errno 108 on access to
the filesystem.

>
> The place to make changes is in your shutdown scripts.  Either change the
> shutdown order, so the file system is not dismounted when it is still
> needed, or remove the -f flag (if you think that will solve the problem).

These are not *my* shutdown scripts, but scripts provided by the distribution
scripts. I can certainly write bug reports to the distribution init-scripts,
but these are so many distributions, that I think I will be successfull.

I still don't see why, but we could also add another fuse option.


Cheers,
Bernd

--
Bernd Schubert
Q-Leap Networks GmbH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Tue, 22 Jul 2008, Bernd Schubert wrote:

> Hello Miklos,
>
> fuse presently kills connections when the -f umount flag is given, even if
> there are still open filedescriptors. At least debian and ubuntu umount
> scripts add the force flag by default on system halt/reboot. Access
> to /usr, /etc and so will then end in "transport endpoint is not connected"
> and further run level scripts to finish the system shutdown can't run and so
> the system deadlocks.
>
> Could you please consinder the patch below?

Well, the point of the "force" flag is to try to umount whatever
happens.  Aborting operations can help resolve deadlocks in a buggy
filesystem even if the filesystem is busy, and that's a feature I
wouldn't want to lose.

Hmm, what does NFS do in this case?  Does it just keep working after
an "umount -f" if it was busy?

Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Bernd Schubert-5]

On Wednesday 23 July 2008 11:44:32 Miklos Szeredi wrote:

> On Tue, 22 Jul 2008, Bernd Schubert wrote:
> > Hello Miklos,
> >
> > fuse presently kills connections when the -f umount flag is given, even
> > if there are still open filedescriptors. At least debian and ubuntu
> > umount scripts add the force flag by default on system halt/reboot.
> > Access to /usr, /etc and so will then end in "transport endpoint is not
> > connected" and further run level scripts to finish the system shutdown
> > can't run and so the system deadlocks.
> >
> > Could you please consinder the patch below?
>
> Well, the point of the "force" flag is to try to umount whatever
> happens.  Aborting operations can help resolve deadlocks in a buggy
> filesystem even if the filesystem is busy, and that's a feature I
> wouldn't want to lose.
>
> Hmm, what does NFS do in this case?  Does it just keep working after
> an "umount -f" if it was busy?

NFS won't unmount it if there are still open filedescriptors. The force flag
is to make unmounting work even if the connection to the server is broken,
but only if the filesystem is not use (with broken connection then finding
out processes with fd's on the nfs mount point is almost impossible).

Actually I could live with the present fuse force approach, if it wouldn't
leave the mount-point in an unusable state. But just closing the connection
and not killing applications having open filedescriptors will cause errno 108
on further access to the mount point (which is hardly acceptable). On the
other hand, killing all corresponding applications is also no option, since
this would also kill the start-stop scripts :(

So if it is really useful (for sshfs?) we should make it configurable.


Cheers,
Bernd

--
Bernd Schubert
Q-Leap Networks GmbH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Wed, 23 Jul 2008, Bernd Schubert wrote:
> NFS won't unmount it if there are still open filedescriptors. The
> force flag is to make unmounting work even if the connection to the
> server is broken, but only if the filesystem is not use (with broken
> connection then finding out processes with fd's on the nfs mount
> point is almost impossible).

OK.

> Actually I could live with the present fuse force approach, if it
> wouldn't leave the mount-point in an unusable state. But just
> closing the connection and not killing applications having open
> filedescriptors will cause errno 108 on further access to the mount
> point (which is hardly acceptable).

Why is this bad?  What problems does this cause on shutdown?

Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Bernd Schubert-5]

On Wednesday 23 July 2008 13:32:44 Miklos Szeredi wrote:

> On Wed, 23 Jul 2008, Bernd Schubert wrote:
> > NFS won't unmount it if there are still open filedescriptors. The
> > force flag is to make unmounting work even if the connection to the
> > server is broken, but only if the filesystem is not use (with broken
> > connection then finding out processes with fd's on the nfs mount
> > point is almost impossible).
>
> OK.
>
> > Actually I could live with the present fuse force approach, if it
> > wouldn't leave the mount-point in an unusable state. But just
> > closing the connection and not killing applications having open
> > filedescriptors will cause errno 108 on further access to the mount
> > point (which is hardly acceptable).
>
> Why is this bad?  What problems does this cause on shutdown?
>

The system won't continue to shutdown - access to all system union mounts
(e.g. /etc, /var, /usr, /bin, /lib and son)  doesn't work anymore, so all
other shutdown scripts won't run. I'm also working on elemination of the /
access deadlock, so even / will have the problem in the future.
This is with unionfs-fuse, which we use and which I'm working on for entire
system unionfs. And except rather annoying shutdown problems it works quite
well (already for 1.5 years in production on 50 desktop systems and since
several month on all of our HPC cluster system - several hundred systems).
I know how to handle these shutdown problems, but I guess most other admins
don't - so this keeps people away to use unionfs-fuse, which reduces the
chances people will report bugs I don't know about yet ;)

Cheers,
Bernd

--
Bernd Schubert
Q-Leap Networks GmbH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Wed, 23 Jul 2008, Bernd Schubert wrote:
> The system won't continue to shutdown - access to all system union mounts
> (e.g. /etc, /var, /usr, /bin, /lib and son)  doesn't work anymore, so all
> other shutdown scripts won't run. I'm also working on elemination of the /
> access deadlock, so even / will have the problem in the future.

So if those mounts are needed for shutdown, why are they being
umounted?

What would happen if they weren't busy, so they would get properly
umounted, yet some script needed to access the contents later?  Having
filesystems kept mounted because some process happens to have an open
file or a cwd on them seems more of an accident than anything else.

> This is with unionfs-fuse, which we use and which I'm working on for entire
> system unionfs. And except rather annoying shutdown problems it works quite
> well (already for 1.5 years in production on 50 desktop systems and since
> several month on all of our HPC cluster system - several hundred systems).
> I know how to handle these shutdown problems, but I guess most other admins
> don't - so this keeps people away to use unionfs-fuse, which reduces the
> chances people will report bugs I don't know about yet ;)

Is this problem specific to unionfs-fuse?

Thanks,
Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Bernd Schubert-5]

On Wednesday 23 July 2008 18:52:21 Miklos Szeredi wrote:
> On Wed, 23 Jul 2008, Bernd Schubert wrote:
> > The system won't continue to shutdown - access to all system union mounts
> > (e.g. /etc, /var, /usr, /bin, /lib and son)  doesn't work anymore, so all
> > other shutdown scripts won't run. I'm also working on elemination of the
> > / access deadlock, so even / will have the problem in the future.
>
> So if those mounts are needed for shutdown, why are they being
> umounted?

The shutdown scripts try to umount everything they can.

>
> What would happen if they weren't busy, so they would get properly
> umounted, yet some script needed to access the contents later?  Having
> filesystems kept mounted because some process happens to have an open
> file or a cwd on them seems more of an accident than anything else.

If your libc is on the union-mount point (or any other fuse filesystem), there
is no chance to umount it (except with -l). Anyway, there is absolutely no
reason to umount it at all, so the umount shall simply fail, but not kill the
filesystem.
In our cases after a clean umount the shutdown process still would work. If it
wouldn't work, I would simply open a filedescriptor in unionfs-fuse of the
mountpoint to prevent an umount.

But all of this is not the point, the point is, that a umount (forced or not
forced) should either cleanly umount the filesystem or fail, but not leave it
in an errno 108 state.
If the errno 108 state might be useful, it should be configurable, at least.

>
> > This is with unionfs-fuse, which we use and which I'm working on for
> > entire system unionfs. And except rather annoying shutdown problems it
> > works quite well (already for 1.5 years in production on 50 desktop
> > systems and since several month on all of our HPC cluster system -
> > several hundred systems). I know how to handle these shutdown problems,
> > but I guess most other admins don't - so this keeps people away to use
> > unionfs-fuse, which reduces the chances people will report bugs I don't
> > know about yet ;)
>
> Is this problem specific to unionfs-fuse?

No, but I'm not so sure how many people use other fuse-filesystems as their
root-fs.


Cheers,
Bernd


--
Bernd Schubert
Q-Leap Networks GmbH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Wed, 23 Jul 2008, Bernd Schubert wrote:

> On Wednesday 23 July 2008 18:52:21 Miklos Szeredi wrote:
> > On Wed, 23 Jul 2008, Bernd Schubert wrote:
> > > The system won't continue to shutdown - access to all system union mounts
> > > (e.g. /etc, /var, /usr, /bin, /lib and son)  doesn't work anymore, so all
> > > other shutdown scripts won't run. I'm also working on elemination of the
> > > / access deadlock, so even / will have the problem in the future.
> >
> > So if those mounts are needed for shutdown, why are they being
> > umounted?
>
> The shutdown scripts try to umount everything they can.

Which is a bug.  What if /bin is on a mount?  There'll be no file
descriptor to keep it open, and scripts won't work too well after it's
been umounted.  This has nothing to do with fuse, and everything to do
with how the shutdown scripts umount filesystems.  Am I missing
something?

> But all of this is not the point, the point is, that a umount
> (forced or not forced) should either cleanly umount the filesystem
> or fail, but not leave it in an errno 108 state.

Well, *real* forced umounting should switch all open file descriptors,
cwd, memory mappings, etc. to refer to dummy files, and then cleanly
umount the filesystem.  But from the application's point of view it
would be the same: any further access to the filesystem through the
file descriptors or through other means would return an error.

There's no cleaner way to force an umount, it *will* result in errors,
period.

>  If the errno 108
> state might be useful, it should be configurable, at least.

I really don't want to do this.  How hard would it be to just fix the
broken umounting script instead?

> > Is this problem specific to unionfs-fuse?
>
> No, but I'm not so sure how many people use other fuse-filesystems as their
> root-fs.

Right, that's not a very common thing, and I think it's reasonable to
expect that things will not work smoothly without some support from
the init scripts.  For example how is the unionfs-fuse process
prevented from being killed by the shutdown script?

Thanks,
Miklos


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Allen Pulsifer-3]

Since I've been following this thread....

I would note that http://linux.die.net/man/8/umount says "-f  Force unmount
(in case of an unreachable NFS system)."

I'm not worried about this specific case (attempting to umount the root file
system when it is still in use).  My concern is that the umount -f that
Debian etc. are doing on shutdown might bypass normal file system shutdown
even if the file system is not hung.  If so, that could be a problem for
many file systems.  It might be better to do a clean shutdown if possible
even when -f is specified, and force a disconnect only if the file system
process is still responsive.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Wed, 23 Jul 2008, Allen Pulsifer wrote:
> Since I've been following this thread....
>
> I would note that http://linux.die.net/man/8/umount says "-f  Force unmount
> (in case of an unreachable NFS system)."

http://linux.die.net/man/2/umount

"MNT_FORCE (since Linux 2.1.116)
    Force unmount even if busy. (Only for NFS mounts.)"
                          ^^^^
Ha!

They seem to agree about the NFS only thing though.

> I'm not worried about this specific case (attempting to umount the root file
> system when it is still in use).  My concern is that the umount -f that
> Debian etc. are doing on shutdown might bypass normal file system shutdown
> even if the file system is not hung.  If so, that could be a problem for
> many file systems.  It might be better to do a clean shutdown if possible
> even when -f is specified, and force a disconnect only if the file system
> process is still responsive.

ITYM unresponsive.

Yes, something like that.  Using 'umount -f' indiscriminately like
that seems rather stupid.

Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Allen Pulsifer-3]

> Using 'umount -f' indiscriminately
> like that seems rather stupid.

Can't argue with that.  Unfortunately, that is not the first stupid mod
Debian has made (and it won't be the last).

How would you recommend shutting down the file system?

  umount
  while test "`pidof <exename>`" != ""; do sleep 1; done

with a timeout added to the while loop and then kill -9 the process if the
loop times out?  Under what circumstances would you use umount -f?  Only to
recover the mount point when the system is not shutting down?


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Szabolcs Szakacsits]

Bernd Schubert <bs@...> writes:
> On Wednesday 23 July 2008 18:52:21 Miklos Szeredi wrote:
>
> > Is this problem specific to unionfs-fuse?
>
> No, but I'm not so sure how many people use other fuse-filesystems as their
> root-fs.

Some distributions use ntfs-3g as root-fs. The most popular is WUBI (Ubuntu).
I was told there are some hundred thousands users. You may check it out how
they are doing (for me this seems to be a distribution, not fuse problem).

     Szaka

--
NTFS-3G: http://ntfs-3g.org


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Bernd Schubert-5]

On Wed, Jul 23, 2008 at 09:05:44PM +0200, Miklos Szeredi wrote:

> On Wed, 23 Jul 2008, Bernd Schubert wrote:
> > On Wednesday 23 July 2008 18:52:21 Miklos Szeredi wrote:
> > > On Wed, 23 Jul 2008, Bernd Schubert wrote:
> > > > The system won't continue to shutdown - access to all system union mounts
> > > > (e.g. /etc, /var, /usr, /bin, /lib and son)  doesn't work anymore, so all
> > > > other shutdown scripts won't run. I'm also working on elemination of the
> > > > / access deadlock, so even / will have the problem in the future.
> > >
> > > So if those mounts are needed for shutdown, why are they being
> > > umounted?
> >
> > The shutdown scripts try to umount everything they can.
>
> Which is a bug.  What if /bin is on a mount?  There'll be no file
> descriptor to keep it open, and scripts won't work too well after it's
> been umounted.  This has nothing to do with fuse, and everything to do
> with how the shutdown scripts umount filesystems.  Am I missing
> something?

Yes, I agree it is a bug of the shutdown scripts.

>
> > But all of this is not the point, the point is, that a umount
> > (forced or not forced) should either cleanly umount the filesystem
> > or fail, but not leave it in an errno 108 state.
>
> Well, *real* forced umounting should switch all open file descriptors,
> cwd, memory mappings, etc. to refer to dummy files, and then cleanly
> umount the filesystem.  But from the application's point of view it
> would be the same: any further access to the filesystem through the
> file descriptors or through other means would return an error.
>
> There's no cleaner way to force an umount, it *will* result in errors,
> period.
>
> >  If the errno 108
> > state might be useful, it should be configurable, at least.
>
> I really don't want to do this.  How hard would it be to just fix the
> broken umounting script instead?

It is not difficult, it is just difficult to figure out all these
distributions doing it wrong. And I know these discussions, the package
maintainers come up with similar arguments to leave their scripts as
they are.

Would you accept a patch which would add an option to disable forced
umounts?

>
> > > Is this problem specific to unionfs-fuse?
> >
> > No, but I'm not so sure how many people use other fuse-filesystems as their
> > root-fs.
>
> Right, that's not a very common thing, and I think it's reasonable to
> expect that things will not work smoothly without some support from
> the init scripts.  For example how is the unionfs-fuse process
> prevented from being killed by the shutdown script?

That is another sad point. We have submitted for sysvinit/killall5 to
not kill fuse binaries in general. Unfortunately it wasn't accepted, but now
needs to be configured by the admin.


Sorry for bothering you with this issue.

Cheers,
Bernd

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Wed, 23 Jul 2008, Allen Pulsifer wrote:
> How would you recommend shutting down the file system?
>
>   umount
>   while test "`pidof <exename>`" != ""; do sleep 1; done
>
> with a timeout added to the while loop and then kill -9 the process if the
> loop times out?

This "how to properly deal with fuse filesystem at shutdown" is an
interesting question that I've been meaning to think about, but
haven't gotten around to doing.  It has interactions with both killing
the processes and umounting filesystems.  And it's definitely not
trivial.  Unprivileged filesystems shouldn't be able to hold up the
shutdown indefinitely, but privileged filesystems must have enough
time to be able to sync contents to disk.

>  Under what circumstances would you use umount -f?  Only to
> recover the mount point when the system is not shutting down?

Recovering the mountpoint is best achieved with 'umount -l'.  I don't
really see a situation during shutdown when 'umount -f' makes any
sense at all.

Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Thu, 24 Jul 2008, Bernd Schubert wrote:
> Would you accept a patch which would add an option to disable forced
> umounts?

As I said, I don't want to do that.  It makes no sense to work around
a problem in userspace scripts this way.  And anyway, changes made to
the kernel generally drift down to the distros very very slowly.  My
feeling is that reporting the bug to the debian package and possibly
even helping them fix it, by submitting a patch would solve this
_much_ quicker than adding a