NFSv4 client's BUG?
Wei Yongjun
yjwei at cn.fujitsu.com
Tue Jul 1 22:30:14 EDT 2008
Daniel Ellard wrote:
> Wei Yongjun wrote:
>> Ellard, Daniel wrote:
>>> You're never closing filedes[i], and eventually you're running out of
>>> file descriptors.
>>>
>>> Add
>>> close(filedes[i]);
>>>
>>> After
>>>
>>> write(filedes[i], "...
>>>
>>
>> This is not the problem. Because I used ulimit -n 5000 to let program
>> can open 5000 files.
>
> Well, it's *a* problem, even if it's not *the* problem.
>
> Another candidate: writing 23 bytes when there are only 11 bytes in
> the string. Probably wouldn't cause this, but who knows.
>
> Randomness is worrisome. Let's see if we can narrow things down at all:
>
> - What happens when you run this on a local file system? Same thing?
local file system has no problem.
>
> - Are you cleaning out the directory every time, or are you beginning
> each run with an arbitrary number of temp files left over from before?
> (maybe mkstemp is confused by large numbers of files in its space)
> Does cleaning out the directory make the program break in a
> predictable manner?
Yes, I clean the directory every time. But if I do not clean the
directory, the error will happend more frequency. Even if the total
number is 1300, the error may happend. So maybe there is some race
between mkstemp() and fopen().
>
> -Dan
More information about the NFSv4
mailing list