Lind Fuse Hangs on Mount

[cmatthew]

Lind Fuse hangs on mount if you access the file system too soon after it is created. This is most easily elicited by using the fuse mount in a shell script on the line right after mounting it.

#!/bin/bash
lind_fuse.py ./mnt
cp foo ./mnt/foo # problem here

In this case the cp will hang. Adding a short sleep after the mount fixes the problem.

[NitinJami]

So, the problem occurs when you mount fuse without "-f" option. I think this is specific to fuse itself, because I couldn't see anything handling this option in lind_fuse.py. This makes fuse go crazy. Adding this option will not create anymore hang-ups.

A quick reference to "man fuser", points that "-f" will mount the filesystem in writable mode, which will also get rid of "Permission denied" errors, while copying.

Having said that, fuse is a slow process and runs in the background which allows the above shell process to run the "cp" cmd even before the fuse is initialized, this will create "Mountpoint not empty" error. Since, the files have been already copied into the mount point.

Adding a sleep inside lind_fuse.py will only make things worse, and the sleep should be added external to fuse process (whatever automatic scripts you are using fuse for).

#!/bin/bash

# run this script in $REPY_PATH/repy/

python lind_fuse.py -f ~/tmp/lind/mount/ &
sleep 2
cp -r ~/foo/ ~/tmp/lind/mount/
rm -rf ~/tmp/lind/mount/foo
fusermount -u ../mount

[cmatthew]

Can't we make lind_fuse mount, wait, then exit? I don't understand why that would be an issue?

On 2013-03-24, at 12:02 PM, Nitin Jami notifications@github.com wrote:

So, the problem occurs when you mount fuse without "-f" option. I think this is specific to fuse itself, because I couldn't see anything handling this option in lind_fuse.py. This makes fuse go crazy. Adding this option will not create anymore hang-ups.

A quick reference to "man fuser", points that "-f" will mount the filesystem in writable mode, which will also get rid of "Permission denied" errors, while copying.

Having said that, fuse is a slow process and runs in the background which allows the above shell process to run the "cp" cmd even before the fuse is initialized, this will create "Mountpoint not empty" error. Since, the files have been already copied into the mount point.

Adding a sleep inside lind_fuse.py will only make things worse, and the sleep should be added external to fuse process (whatever automatic scripts you are using fuse for).

!/bin/bash

run this script in $REPY_PATH/repy/

python lind_fuse.py -f ~/tmp/lind/mount/ & sleep 2 cp -r ~/foo/ ~/tmp/lind/mount/ rm -rf ~/tmp/lind/mount/foo fusermount -u ../mount — Reply to this email directly or view it on GitHub.

[NitinJami]

Sorry, for getting back late. Got stuck up with other work.

fuse needs to run as a background service, for the entire time we try to interact with the mounted file system (if you want both of them to be under the same parent process, here the shell script) right? So, once your sending the fuse to background using '&', the next cp command kicks in even before the fuse loads, putting a sleep inside fuse will further delay the loading time.

If you don't want fuse to run as a background service, then the interaction with the mounted file system should be done under different parent process. You cannot have fuse running as foreground and interaction under same parent process.

[cmatthew]

I think this has to do with how the driver program we wrote works, not how fuse runs in the background.

Chris Matthews, PhD Candidate University of Victoria, Canada http://www.christophermatthews.ca

On 2013-03-26, at 1:19 PM, Nitin Jami notifications@github.com wrote:

Sorry, for getting back late. Got stuck up with other work.

fuse needs to run as a background service, the entire time we try to interact with the mounted file system (if you want both of them to be under the same parent process, here the shell script) right? So, once your sending the fuse to background using '&', the next cp command kicks in even before the fuse loads, putting a sleep inside fuse will further delay the loading time.

If you don't want fuse to run as a background service, then the interaction with the mounted file system should be done under different parent process. You cannot have fuse running as foreground and interaction under same parent process.

— Reply to this email directly or view it on GitHubhttps://github.com/cmatthew/Lind-misc/issues/46#issuecomment-15485788 .

[rickmcgeer]

Change your sig. You're a PhD now, not a candidate.

On Tue, Mar 26, 2013 at 10:54 PM, Chris Matthews notifications@github.comwrote:

I think this has to do with how the driver program we wrote works, not how fuse runs in the background.

Chris Matthews, PhD Candidate University of Victoria, Canada http://www.christophermatthews.ca

On 2013-03-26, at 1:19 PM, Nitin Jami notifications@github.com wrote:

Sorry, for getting back late. Got stuck up with other work.

fuse needs to run as a background service, the entire time we try to interact with the mounted file system (if you want both of them to be under the same parent process, here the shell script) right? So, once your sending the fuse to background using '&', the next cp command kicks in even before the fuse loads, putting a sleep inside fuse will further delay the loading time.

If you don't want fuse to run as a background service, then the interaction with the mounted file system should be done under different parent process. You cannot have fuse running as foreground and interaction under same parent process.

— Reply to this email directly or view it on GitHub< https://github.com/cmatthew/Lind-misc/issues/46#issuecomment-15485788> .

— Reply to this email directly or view it on GitHubhttps://github.com/cmatthew/Lind-misc/issues/46#issuecomment-15505558 .

[NitinJami]

@rickmcgeer lol

@cmatthew ah, so you are saying you also modified some parts of core fuse, lind_fuse seems to be pretty straight forward and nothing magic happens over here, until the Fuse.main() is called. I will try and see if there are other implementations of fuse and how they do it.

[cmatthew]

Good idea! Thanks Rick!

Christopher Matthews, Ph.D. Cupertino, CA http://www.christophermatthews.ca

On 2013-03-27, at 1:14 AM, rickmcgeer notifications@github.com wrote:

Change your sig. You're a PhD now, not a candidate.

On Tue, Mar 26, 2013 at 10:54 PM, Chris Matthews notifications@github.comwrote:

I think this has to do with how the driver program we wrote works, not how fuse runs in the background.

Chris Matthews, PhD Candidate University of Victoria, Canada http://www.christophermatthews.ca

On 2013-03-26, at 1:19 PM, Nitin Jami notifications@github.com wrote:

Sorry, for getting back late. Got stuck up with other work.

fuse needs to run as a background service, the entire time we try to interact with the mounted file system (if you want both of them to be under the same parent process, here the shell script) right? So, once your sending the fuse to background using '&', the next cp command kicks in even before the fuse loads, putting a sleep inside fuse will further delay the loading time.

If you don't want fuse to run as a background service, then the interaction with the mounted file system should be done under different parent process. You cannot have fuse running as foreground and interaction under same parent process.

— Reply to this email directly or view it on GitHub< https://github.com/cmatthew/Lind-misc/issues/46#issuecomment-15485788> .

— Reply to this email directly or view it on GitHub< https://github.com/cmatthew/Lind-misc/issues/46#issuecomment-15505558> .

— Reply to this email directly or view it on GitHubhttps://github.com/cmatthew/Lind-misc/issues/46#issuecomment-15509958 .

[cmatthew]

I didn't modify core. But just the way the start is called could be wrong.

Christopher Matthews, Ph.D. Cupertino, CA http://www.christophermatthews.ca

On 2013-03-27, at 7:39 AM, Nitin Jami notifications@github.com wrote:

@rickmcgeer https://github.com/rickmcgeer lol

@cmatthew https://github.com/cmatthew ah, so you are saying you also modified some parts of core fuse, lind_fuse seems to be pretty straight forward and nothing magic happens over here, until the Fuse.main() is called. I will try and see if there are other implementations of fuse and how they do it.

— Reply to this email directly or view it on GitHubhttps://github.com/cmatthew/Lind-misc/issues/46#issuecomment-15526950 .