fs-cifs //smbserver:10.0.0.200:/shared /server username password
I can now see the cifs directory mounted on /server.
If I lose the network connection (i.e. I unplug the ethernet cable),
doing open() on any file on /server would block the call until I plug
the cable back in.
What I’d like to do is to set up a timeout on the open call,
I first thought that I could do this by simply wrapping the open() in my
open_nb() function.
fs-cifs //smbserver:10.0.0.200:/shared /server username password
I can now see the cifs directory mounted on /server.
If I lose the network connection (i.e. I unplug the ethernet cable),
doing open() on any file on /server would block the call until I plug
the cable back in.
What I’d like to do is to set up a timeout on the open call,
I first thought that I could do this by simply wrapping the open() in my
open_nb() function.
Open should not block in the first place, looks like a bug in fs-cifs. That
being said, I think using TimerTimeout with open is a bad idea.
TimerTimeout is use to timeout kernel calls. You code makes assumption on
what open() does, there is nothing in the specs that says open can’t do
retry. Maybe open is made up of more then one kernel call (MsgSend) hence
the first one times out but not the subsequent one.
return open(path, O_RDONLY);
}
The call I made was:
int fd = open_nb("/server/testfile");
This call still resulted in my program being REPLY-blocked indefinetely
(from pidin).
MC > Open should not block in the first place, looks like a bug in fs-cifs. That
MC > being said, I think using TimerTimeout with open is a bad idea.
MC > TimerTimeout is use to timeout kernel calls. You code makes assumption on
MC > what open() does, there is nothing in the specs that says open can’t do
MC > retry. Maybe open is made up of more then one kernel call (MsgSend) hence
MC > the first one times out but not the subsequent one.
I believe that your right about the multiple kernel calls. Though there
should be a hook to get around it. I often have problems with cifs opens
taking too long too.
Mario, I don’t understand how you can say that open() “should not block”.
Go back to the System Architecture and look at what happens during an
open(). How can it not block, even when talking to a local file system.
Now send that erquest out over a network and your going from milliseconds
of latency to seconds.
Your code makes assumption on
what open() does, there is nothing in the specs that says open can’t do
retry. Maybe open is made up of more then one kernel call (MsgSend) hence
the first one times out but not the subsequent one.
open() definitely makes more than one kernel call. At minimum it does
a message pass exchange with Proc to find who owns the name you’re trying
to open, then creates a connection to that resource manager, then does
a message pass exchange sending an _IO_OPEN message to that resource
manager.
-David
return open(path, O_RDONLY);
}
The call I made was:
int fd = open_nb("/server/testfile");
This call still resulted in my program being REPLY-blocked indefinetely
(from pidin).
Any idea anyone??
You may have to revert to using a timer-driven signal for this
timeout.
MC > Open should not block in the first place, looks like a bug in
fs-cifs. That
MC > being said, I think using TimerTimeout with open is a bad idea.
MC > TimerTimeout is use to timeout kernel calls. You code makes
assumption on
MC > what open() does, there is nothing in the specs that says open can’t
do
MC > retry. Maybe open is made up of more then one kernel call (MsgSend)
hence
MC > the first one times out but not the subsequent one.
I believe that your right about the multiple kernel calls. Though there
should be a hook to get around it. I often have problems with cifs opens
taking too long too.
Use alarm() instead ? If that still not acceptable, you have to use your own
timer.