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
> (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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message