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
>     later.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to