> On 11 Nov 99 at 00:45, Michael Nelson wrote:
> > I noticed this weekend that "rm -rf" doesn't work very well on SMBFS
> > because as its dircache gets repopulated, a whole bunch of entries are
> > skipped which happen to now be below filp->f_pos.
I have never run into this before, but I can easily repeat it.
% tar xvzf /usr/src/linux-2.2.3.tar.gz linux/kernel
% rm -rf linux/
rm: cannot remove directory `linux/kernel': Permission denied
rm: cannot remove directory `linux': Permission denied
Everytime ... (this is on 2.2.13). This particular dir has 21 entries (23
with . and ..).
- smb_readdir: reading linux/kernel, f_pos=0
- the cache is filled
- the entries that were read are unlinked (the first 16).
- smb_invalid_dir_cache is called (on each unlink)
- smb_readdir: reading linux/kernel, f_pos=18
- and here we refill the cache ... oops, now it only has 5 entries left
> > A cursory glance at the NFS and NCPFS file systems seems to show that the
> > former doesn't have this problem, but NCPFS may.
How does nfs do this?
> tree). We now build complete dentries and inodes not only in lookup, but in
> readdir too (we can do this as NCP directory scan function can return
> all important inode data). We set dentry's d_fsdata to position in directory
> and as this field is revalidated only if directory is reread, it will
> work for 'rm -rf' too (it is NOT revalidated/invalidated on unlink/rmdir).
Does the inodes matter here, or is it just that you need it for the rest
of what you do? smbfs could read all the info at once as well and create
the inodes, if that is necessary. (I think there are 5 or 6 variations of
directory scan functions ... :)
> 2) if you do 'rm -f dir' together with 'while true; do ls dir; done',
> 'ls' can (and will) cause renumbering of directory entries.
Does this describe how it works?
% ls
(fills the cache)
% rm some_file
(removes the file but does not invalidate the cache)
% ls
(reread the cache beacuse the mtime has changed)
% ls
(fills the cache)
% ls
(reuse the cache since mtime is unchanged)
smbfs invalidates the cache when adding or removing files or dirs,
on rename and (sometimes) when refreshing/revalidating an inode. Changing
it to use the dirs mtime should be as simple as ... no, I can't get it to
work now. It keeps invalidating the cache for me :(
I tried adding a mtime variable to cache_head, check for it in readdir,
set it in smb_refill_dircache and remove calls to smb_invalid_dir_cache.
I'm missing something.
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/