Re: dcache problems with vfat

Gordon Chaffee (chaffee@cs.berkeley.edu)
Tue, 5 Jan 1999 00:50:12 -0800 (PST)

Andries.Brouwer@cwi.nl writes:
> # mount /dev/foo /mnt -t vfat
> # cd /mnt; touch file; mkdir dir; cd dir; mv ../file .
> # cd /mnt/dir/file
> bash: /mnt/dir/file: Not a directory
> # rm file; cd ..; rmdir dir
>
> rmdir: Device or resource busy
> What happens? The "cd /mnt/dir/file" needs the dcache
> entry of dir, but the revalidate fails because dir was
> timestamped with the version of /mnt, but that changed
> when mv ../file . was done. So, the old entry for dir
> is dropped and a new lookup is done.
> However, the old entry pointed at the same inode as the
> new one, so that now i_count=2 and the rmdir fails.
>
> The abovementioned bug is easily reproduced, and still present
> in 2.2.0pre4. It is also easy to give patches that make this
> particular bug go away, but before doing so I would like to
> convince myself that vfat+patches satisfies the obligations.
> But what are these precisely (say, for revalidate)?

Its been awhile since I've made any changes to the code and so I am
still running 2.1.121 with some of my own modifications. Then, the
problem did not exist and everything worked fine. I saw that some
significant changes were made around 2.1.130 to some of the dcache
code that had a significant impact on vfat, but I haven't been working
with any of these. It took me quite awhile to get all (or at least most)
of the problems dealt with so that my test suite was happy again before
the latest set of changes was made, and I was happy with where things
were given the code freeze. However, it seems that whatever changes
were made once again made the vfat code unstable, and I haven't had
time to look for all the problems again. I've been busy with a startup,
so I haven't been keeping on top of things.

- Gordon

-
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/