making fuse mount hang

[Mohit Aron]

Hello,

if the process that receives the fuse upcalls crashes, fuse seems to
automatically unmount the mount point. Is there some way to change this
behavior so that the mount point still exists but all attempts to access it
(other than an explicit 'umount -f') just get blocked ?

The reason I need this functionality is that if I'm using 'fuse' to
implement a filesystem, and my fuse user process crashes, I'd like the
application use the fuse mount to hang until some fault-tolerance mechanism
kicks in and restarts the fuse user process. If a crash of the fuse user
process automatically unmounts the underlying mount, the application would
now start accessing the filesystem under the mount point (possibly ext3).
That would make the application see incorrect data.



- Mohit
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Wed, 9 Jul 2008, Mohit Aron wrote:
> if the process that receives the fuse upcalls crashes, fuse seems to
> automatically unmount the mount point. Is there some way to change this
> behavior so that the mount point still exists but all attempts to access it
> (other than an explicit 'umount -f') just get blocked ?
>
> The reason I need this functionality is that if I'm using 'fuse' to
> implement a filesystem, and my fuse user process crashes, I'd like the
> application use the fuse mount to hang until some fault-tolerance mechanism
> kicks in and restarts the fuse user process.

You should rather make the filesystem fault tolerant by not crashing ;)

Seriously, what you require is impossible: one mount cannot magically
replace another with all open files, etc migrated to the new one.

If such high level of fault tolerance is really an issue (I suspect
not, it's much easier to just fix the bugs), then you can write a
simple persistent layer that forwards requests to another, restartable
layer which has all the complexity.

But I really woulnd't worry about such things at the early stages of
filesystem development.

Miklos

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Mohit Aron]

>
> You should rather make the filesystem fault tolerant by not crashing ;)
>
> Seriously, what you require is impossible: one mount cannot magically
> replace another with all open files, etc migrated to the new one.
>


Well, no matter how well one writes code, crashes do happen sometimes - and
I'd like the application to be shielded from it. With rapid development of a
complex filesystem, it becomes even harder.

I could definitely get the desired effect with say an NFS server which runs
on the same machine - if the server crashes, the mount point is hung, and
the NFS server can be restarted safely.

In fact, I was wondering about the advantages/disadvantages of using fuse vs
a loopback NFS server. Any thoughts on that ? The one disadvantage that's
keeping me from going that route is that the freely available sunrpc library
is not multi-threaded and it takes some work to make it so. Without that,
essentially the NFS server can only have one request outstanding at any
time. One of the past companies I worked for built a user-level distributed
NFS server and it had to solve that issue.


>
> If such high level of fault tolerance is really an issue (I suspect
> not, it's much easier to just fix the bugs), then you can write a
> simple persistent layer that forwards requests to another, restartable
> layer which has all the complexity.
>

That would involve yet another context switch and more data copying - in the
short term, I'll just work with making both the application as well as the
fuse process crash together and restart both of them if necessary.


- Mohit
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Fri, 11 Jul 2008, Mohit Aron wrote:
> Well, no matter how well one writes code, crashes do happen sometimes - and
> I'd like the application to be shielded from it. With rapid development of a
> complex filesystem, it becomes even harder.
>
> I could definitely get the desired effect with say an NFS server which runs
> on the same machine - if the server crashes, the mount point is hung, and
> the NFS server can be restarted safely.

As I said, you can do this with fuse as well, as long as the
filesystem is not umounted.  Umouning then mounting an NFS volume
wouldn't work either.

> In fact, I was wondering about the advantages/disadvantages of using fuse vs
> a loopback NFS server. Any thoughts on that ? The one disadvantage that's
> keeping me from going that route is that the freely available sunrpc library
> is not multi-threaded and it takes some work to make it so. Without that,
> essentially the NFS server can only have one request outstanding at any
> time. One of the past companies I worked for built a user-level distributed
> NFS server and it had to solve that issue.

NFS server on the same host as the client has other problems as well,
like for example it's prone to deadlock on memory pressure.  Which is
a problem that has been explicitly avoided in the fuse design.

> > If such high level of fault tolerance is really an issue (I suspect
> > not, it's much easier to just fix the bugs), then you can write a
> > simple persistent layer that forwards requests to another, restartable
> > layer which has all the complexity.
> >
>
> That would involve yet another context switch and more data copying - in the
> short term, I'll just work with making both the application as well as the
> fuse process crash together and restart both of them if necessary.

Actually, not even such a layer is needed.  What is needed is just a
process that keeps the fuse device open, and can respawn the real
server, passing it the file descriptor.  Currently this would involve
some lowlevel hacking of libfuse (or avoiding its use altogether),
because this isn't something the library has been designed for.  But
it's should be doable.  I might even include such a feature in future
versions of the library if there's demand for it.

Miklos

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Mohit Aron]

>
> As I said, you can do this with fuse as well, as long as the
> filesystem is not umounted.  Umouning then mounting an NFS volume
> wouldn't work either.


One doesn't need to unmount the NFS volume - just restart the NFS server
when it dies.

>
>
> Actually, not even such a layer is needed.  What is needed is just a
> process that keeps the fuse device open, and can respawn the real
> server, passing it the file descriptor.  Currently this would involve
> some lowlevel hacking of libfuse (or avoiding its use altogether),
> because this isn't something the library has been designed for.  But
> it's should be doable.  I might even include such a feature in future
> versions of the library if there's demand for it.
>

That would be great.  I think it would go a long way towards building
fault-tolerant filesystems using fuse.


- Mohit
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Anand Avati-2]

>
>
> > That would involve yet another context switch and more data copying - in
> the
> > short term, I'll just work with making both the application as well as
> the
> > fuse process crash together and restart both of them if necessary.
>
> Actually, not even such a layer is needed.  What is needed is just a
> process that keeps the fuse device open, and can respawn the real
> server, passing it the file descriptor.  Currently this would involve
> some lowlevel hacking of libfuse (or avoiding its use altogether),
> because this isn't something the library has been designed for.  But
> it's should be doable.  I might even include such a feature in future
> versions of the library if there's demand for it.
>

Just wondering how would the newly spawned process handle the looked up
inode cache? Maybe it is too early to ask this question..

avati
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Sat, 12 Jul 2008, Anand Avati wrote:
> Just wondering how would the newly spawned process handle the looked up
> inode cache? Maybe it is too early to ask this question..

Yes, that's an interesting question.  And the answer is basically the
same as for an NFS server: the filesystem must have persistent node
ID's (file handles for NFS).  The ID's must work after a restart
without having first been looked up.  If the filesystem can't handle
that, it's not suitable for this mode of operation.

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