Hello
I am tracking a rare bug with perfused, where an existing file is
reported as unexistent. It happens after a few hours of usage, and it
happens only once: if I retry accessing the file, I am successful.
Adding traces in perfused while performing ktrace on the calling
process, I am now confi
Emmanuel Dreyfus wrote:
> Hence I come to the conclusion that it may come from
> sys/kern/vfs_lookup.c, but it is very unlikely that there is a bug there
> that went unnoticed for other filesystems.
Further investigation shows that this ENOENT is returned by vget() call
in puffs_cookie2vnode().
hi,
> Emmanuel Dreyfus wrote:
>
>> Hence I come to the conclusion that it may come from
>> sys/kern/vfs_lookup.c, but it is very unlikely that there is a bug there
>> that went unnoticed for other filesystems.
>
> Further investigation shows that this ENOENT is returned by vget() call
> in puff
On Mon, Jan 16, 2012 at 06:25:39AM +, YAMAMOTO Takashi wrote:
> it should retry from puffs_cookie2pnode in that case.
I also need to build a test case that reliabiliy reproduce the bug.
For now I run our build.sh -Uo release and come back the next day,
this is not very convenient.
As I unde
hi,
> On Mon, Jan 16, 2012 at 06:25:39AM +, YAMAMOTO Takashi wrote:
>> it should retry from puffs_cookie2pnode in that case.
>
> I also need to build a test case that reliabiliy reproduce the bug.
> For now I run our build.sh -Uo release and come back the next day,
> this is not very conven
On Mon, Jan 16, 2012 at 10:56:33AM +, YAMAMOTO Takashi wrote:
> you can increase the chance by running
> while :;do sysctl -w kern.maxvnodes=0; done
It will always fail:
bacasable# sysctl -w kern.maxvnodes=0
sysctl: kern.maxvnodes: sysctl() failed with Device busy
--
Emmanuel Dreyfus
On Jan,Monday 16 2012, at 11:58 AM, Emmanuel Dreyfus wrote:
> On Mon, Jan 16, 2012 at 10:56:33AM +, YAMAMOTO Takashi wrote:
>> you can increase the chance by running
>> while :;do sysctl -w kern.maxvnodes=0; done
>
> It will always fail:
> bacasable# sysctl -w kern.maxvnodes=0
> sysct
On Mon, Jan 16, 2012 at 02:02:41PM +0100, Adam Hamsik wrote:
> Just try to lower that number to some smaller one ?
sysctl(7) says:
kern.maxvnodes (KERN_MAXVNODES)
The maximum number of vnodes available on the system. This can
only be raised.
But it seems I can lower it fro
On Mon 16 Jan 2012 at 13:17:17 +, Emmanuel Dreyfus wrote:
> But it seems I can lower it from 26214 to 200 without a hitch. I have
> no idea how mch room it has, however. We cannot get the number of used
> vnode from userland, can we?
pstat -v gives the number of "active" vnodes; that may be us
hello. pstat -v should give you what you want to know.
-thanks
-Brian
On Jan 16, 1:17pm, Emmanuel Dreyfus wrote:
} Subject: Re: PUFFS and existing file that get ENOENT
} On Mon, Jan 16, 2012 at 02:02:41PM +0100, Adam Hamsik wrote:
} > Just try to lower that number to some smaller
hi,
> On Mon, Jan 16, 2012 at 10:56:33AM +, YAMAMOTO Takashi wrote:
>> you can increase the chance by running
>> while :;do sysctl -w kern.maxvnodes=0; done
>
> It will always fail:
> bacasable# sysctl -w kern.maxvnodes=0
> sysctl: kern.maxvnodes: sysctl() failed with Device busy
it t
On Mon, 16 Jan 2012 10:56:33 + (UTC)
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> when the kernel wants to cache other files.
> ie. whenever the kernel decides to reclaim it. :-)
> you can increase the chance by running
> while :;do sysctl -w kern.maxvnodes=0; done
> or something l
hi,
> On Mon, 16 Jan 2012 10:56:33 + (UTC)
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
>
>> when the kernel wants to cache other files.
>> ie. whenever the kernel decides to reclaim it. :-)
>> you can increase the chance by running
>> while :;do sysctl -w kern.maxvnodes=0; done
>>
On Mon, 16 Jan 2012 22:26:30 + (UTC)
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> hi,
>
> > On Mon, 16 Jan 2012 10:56:33 + (UTC)
> > y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> >
> >> when the kernel wants to cache other files.
> >> ie. whenever the kernel decides to reclaim
YAMAMOTO Takashi wrote:
> > Further investigation shows that this ENOENT is returned by vget() call
> > in puffs_cookie2vnode(). That suggests some kind of race condition, but
> > that is not obvious. It means a vnode has been created on a lookup, then
> > it gets recycled while looking up one of
YAMAMOTO Takashi wrote:
> it should retry from puffs_cookie2pnode in that case.
Here is a patch that works around the problem (I initially had printf to
check it did go through the ENOENT case and it does). I am about to
commit that and pullup to netbsd-5, except if there are comments.
Index: s
hi,
> YAMAMOTO Takashi wrote:
>
>> it should retry from puffs_cookie2pnode in that case.
>
> Here is a patch that works around the problem (I initially had printf to
> check it did go through the ENOENT case and it does). I am about to
> commit that and pullup to netbsd-5, except if there are c
YAMAMOTO Takashi wrote:
> please clean up these unreachable statements.
> otherwise looks ok to me. thanks for fixing.
What do you mean? Removing the break after return and goto?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
> YAMAMOTO Takashi wrote:
>
>> please clean up these unreachable statements.
>> otherwise looks ok to me. thanks for fixing.
>
> What do you mean? Removing the break after return and goto?
yes.
YAMAMOTO Takashi
>
> --
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> m...@netbsd.org
19 matches
Mail list logo
