hi,
what's the intention of the move of the VOP_ACCESS call
in ufs_lookup.c rev.1.112?
the old place seems better to me.
YAMAMOTO Takashi
On Mar 14, 2012, at 10:55 AM, Martin Husemann wrote:
On Tue, Mar 13, 2012 at 06:41:18PM +, Elad Efrat wrote:
Log Message:
Replace the remaining
On Mon, Mar 19, 2012 at 03:28:31AM +, YAMAMOTO Takashi wrote:
what's the intention of the move of the VOP_ACCESS call
in ufs_lookup.c rev.1.112?
the old place seems better to me.
According to what elad told me in private mail the other day, it's to
move the two security checks next to
hi,
Hi
I am runnning my usual perfuse test case on netbsd-6: building the
netbsd tree. Performances are much lower than on netbsd-5.
A quick dump of FUSE operations shows that the thing spends most
of its time on lookups. It will exhibit behavior like this:
LOOKUP a
LOOKUP a/b
Hello,
I stumbled upon something interesting tonight when testing a new
unstable ECL (Embeddable Common Lisp). When built with TLS support
(--with-__threads=yes), a noticeable slowdown can be experienced
compared to with --with-_threads=no. For now, I'm not sure yet if it
has to do with a bug
hi,
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
if your filesystem is not using namecache and the application is using
full paths to look up files, the trace looks normal.
otherwise, it looks weird.
I only have PUFFS_KFLAG_NOCACHE_NAME set when calling puffs_init
On netbsd-5, the
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
LOOKUP x
GETATTR x/y
LOOKUP x
GETATTR x/z
RECLAIM x
RECLAIM x
the behaviour on netbsd-6 is what i expect with PUFFS_KFLAG_NOCACHE_NAME.
probably the flag is broken on netbsd-5?
If netbsd-6 behavvior is right, then indeed the flag was
