On 10 Sep, Bruce Evans wrote: >> The locking changes in union_link() need a thorough review, >> though the light testing of that I performed didn't turn up any >> glaring problems. > > The changes are obviously just cleanups for leaf file systems, but I > wonder why everything wasn't always locked at the top. Could it have > been because locking all the way down is harmful?
Judging by how the leaf filesystems were careful to only do the lock if tdvp != vp, I suspect there was the potential for a deadlock if both vnodes were automatically locked at the top. > The ugly gotos and uglier braces near them could be replaced by simple > returns now. Some related points: We can't change the gotos to returns unless we also make the change in (1). I think I agree with you about (1), but VN_KNOTE() doesn't have a man page and I didn't want to change anything that I didn't understand. I think (1) deserves a separate sweep and mega-commit. A quick look at ufs_vnops.c turns up a number of inconsistencies in the use of VN_KNOTE(). > (1) I think it is just a bug that null changes for failed operations are > knoted. It might be useful for knote to report attempted operations > and why they failed, but reporting failed operations doesn't seem > very useful unless they can be distinguished from successful ones. > Anyway, knote isn't told about failures before here. Doing the > knoting at a higher level upon successful completion would work > better in many cases including the above. This would be similar > to setting file times only upon successful completion, except it is > easier because knotes apply to vnodes but file times are fs-specific. > In both cases, it might be useful to set flags at lower levels in > some cases and back out the settings together with backing out the > main effects of the operation if the operation becomes unsuccessful > later. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
