> I wondered if it is safe for a file system to iterate through the
> d_subdirs and set a flag in the inode? Is any locking needed?
You should be safe if you're just setting a flag and not blocking. But
if any blocking could occur, you'll need to restart the scan from the
top to be safe.
> A second question is the following. I saw that NFS carefully unhashes the
> entry before doing an rmdir. This seems to avoid a race condition between
> different processes gaining access to the dentry. Should all filesystems
> do this? Are similar things the case for rename of directories? (It would
> seem so.) Why does avoiding these race conditions not apply to files?
We're having a lot of trouble in NFS making sure that any operation that
could delete a file or directory on the server won't have the inode
still in use. The issue is that if the server reuses the inode number,
the local copy of the inode could corrupt the new usage on the server.
Unhashing and iputting the inode first avoids a race if the inode number
gets reused. Both directories and files have similar concerns -- see
nfs_safe_remove details.
I would think that coda might share the same concerns, unless it has a
way of knowing that the file or directory is still in use somewhere.
Regards,
Bill