Hi Barry,
On 24 Oct 2007, at 08:39, Barry Naujok wrote:
On Tue, 23 Oct 2007 20:07:47 +1000, Anton Altaparmakov <aia21@xxxxxxxxx
> wrote:
I forgot to say: If you do what I did for NTFS you can also throw
away your custom dentry operations that your patch adds as the dcache
then only holds correctly cased names so you are fine to do case
sensitive dcache lookups at all times. Access via wrongly cased name
will always go to ->lookup inode operation and that is fine because
such lookups almost never happen because majority of users will
either
use a GUI in which case all names are always correctly cased as the
names displayed in the GUI are obtained from a ->readdir and thus
show
the correct case or they will use the command line in which case they
will be savvy enough to use tab-completion in which case the names
are
correct case, too. Tab-completion does not work on wrongly cased
names so you are very unlikely to ever get a wrongly cased name at
all.
And yes of course you can on purpose construct a test / benchmark
where having to do the ->lookup each time will be really slow because
you keep creating files and then accessing them by wrongly cased name
on purpose (or whatever) but I would hope that you do not care about
such artificial benchmarks that do not reflect any real-world
loads...
I have been looking at ntfs_lookup() and seeing how it does its stuff.
It seems that is the best way to go.
One thing I have noticed is with two or more attempted case-
insensitive
lookups that don't exist yet case match the same
(ie. ntfs_lookup_inode_by_name() fails with -ENOENT), d_add(dent,
NULL)
is called, populating the dentry with effective duplicates.
Eg:
# cat /mnt/foo/fileNOTexist
# cat /mnt/foo/FILEnotEXIST
Will have two negative dentries, am I correct?
Yes, that is correct. Well spotted! That means NTFS needs to start
killing all negative dentries belonging to a directory each time a
directory entry is created in that directory. That is what I do for
NTFS on Mac OS X already but I had forgotten about needing to do it on
Linux, too. )-:
In OSX there the VFS provides a function to do this "xnu/bsd/vfs/
vfs_cache.c::cache_purge_negatives()", we will need to implement an
equivalent on Linux:
<quote from xnu/bsd/vfs/vfs_cache.c>
/*
* Purge all negative cache entries that are children of the
* given vnode. A case-insensitive file system (or any file
* system that has multiple equivalent names for the same
* directory entry) can use this when creating or renaming
* to remove negative entries that may no longer apply.
*/
void
cache_purge_negatives(vnode_t vp)
{
struct namecache *ncp;
NAME_CACHE_LOCK();
LIST_FOREACH(ncp, &vp->v_ncchildren, nc_child)
if (ncp->nc_vp == NULL)
cache_delete(ncp, 1);
NAME_CACHE_UNLOCK();
}
</quote>
The Linux version should be analogous AFAICS, i.e. take the dentry of
the directory in which an entry is being created and iterate over its
d_subdirs list and for each dentry on that list if it is a negative
dentry, i.e. d_inode is NULL, throw the dentry away. Basically very
similar to the OSX function but I can't quite see which dcache
function we need to call to do the "throw the dentry away" bit. None
of the functions in fs/dcache.c look quite right. I imagine we want
to take the dcache_lock, traverse d_subdirs list of the directory
dentry and for each negative dentry on the list, do a __dget_locked(),
__d_drop(), spin_unlock(&dentry->d_lock), then move it from d_subdirs
of its parent to a private list and when when we are done, drop the
dcache_lock and go over the private list and do a dput() for each
dentry on the private list which will result in them all being
d_kill()ed. This can probably be made more efficient by someone who
understands the dcache better than me but it seems what I suggest
would at least do the right thing...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
