[sorry for self-followup, but...]
[I wrote:]
> On Fri, 12 May 2000, Jeff V. Merkey wrote:
>
> > I guess the real question here is how much serialization does the VFS
> > provide above you. I discovered last year in my initial forays with
> > Linux that parallelism is fully exposed to the file system. The locks
>
> ->i_sem ->i_zombie
> yes no lookup()
> yes yes readdir(),create(),mknod(),mkdir(),symlink()
> yes yes directory where create a link on link()
> yes yes directory where we remove a link on unlink()
> yes yes directory where we remove a link on rmdir()
> yes yes both parents on rename()
> no yes victim on rmdir()
> no yes target of rename() if it exists and is a directory
>
> > In the case of directories, the locks protect the block count. If the
> > VFS above provides serialization for changes to directory data, this
> > lock can be dropped.
>
> If you are interested in the contents - yes, all operations
> that change directory contents grab ->i_zombie on that directory. See the
> table above - your guarantees are there.
The only case you have to cope with is the lookup() in directory you are
trying to remove. Since it's either empty (and then lookup giives negative)
or attempt to remove should fail with no side effects that's hardly a problem.
Notice that attempts to create something in such directory _will_ block until
removal either succeeds or fails, so you don't have to worry about creation
interfering with emptiness checks.
Another thing is that directory-moving rename()s within the same filesystem
are serialized (different filesystems are independent, indeed).
Parents are always positive and always directories.
-
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/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:21 EST