[Top] [All Lists]

Re: [PATCH 3/4] XFS: Return case-insensitive match for dentry cache

To: "Christoph Hellwig" <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 3/4] XFS: Return case-insensitive match for dentry cache
From: "Barry Naujok" <bnaujok@xxxxxxx>
Date: Wed, 14 May 2008 17:55:45 +1000
Cc: xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, aia21@xxxxxxxxxx
In-reply-to: <20080513085724.GC21919@infradead.org>
Organization: SGI
References: <20080513075749.477238845@chook.melbourne.sgi.com> <20080513080152.911303131@chook.melbourne.sgi.com> <20080513085724.GC21919@infradead.org>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Opera Mail/9.24 (Win32)
On Tue, 13 May 2008 18:57:24 +1000, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:

First please Cc Anton on this as he wrote the original version of
what's now d_add_ci, I suspect he might have some useful comments.

On Tue, May 13, 2008 at 05:57:52PM +1000, Barry Naujok wrote:
Another unusual interaction with the dcache is not storing
negative dentries like other filesystems doing a d_add(dentry, NULL)
when an ENOENT is returned. During the VFS lookup, if a dentry
returned has no inode, dput is called and ENOENT is returned.
By not doing a d_add, this actually removes it completely from
the dcache to be reused.

That is a way to implement this correctly, but I suspect not creating negative dentries will degrade performance quite badly on some workloads. Then again CI is useful only for samba serving where the namecache on the client side should mitigate that effect.

Not quite sure if this is the right test, but I did 1000 creates on a brand new filesystem with and without ci on my SATA drive, both sustained almost 600 creates per second.

I believe creates would be the worst case scenario for not adding
negative dentries?

We'd probably be better off long-term implementing Anton's earlier
suggestion to have a routine that purges all ci aliased negative
dentries on a successfull lookup.


<Prev in Thread] Current Thread [Next in Thread>