Re: serious performance regression in .41

[christos%astron.com@localhost (Christos Zoulas)]

In article <E66F6D98-02A2-4DBB-9EBE-D865B5204A28%eis.cs.tu-bs.de@localhost>,
J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost> wrote:
>
>While I'm interested in the results, this change is wrong.  As long as
>we have forced unmount and revoke it is not safe to access an inode
>without locking the corresponding vnode.  Holding a reference to the
>vnode just guarantees the vnode will not disappear, it does not
>prevent the inode from disappearing.

I had a bug in the initial version but the diff now works. I am
also taking the vnode interlock before accessing the selector
function. I think that this should be enough for the inode not to
dissappear (right?). Note that the ffs code did not take the
interlock before (so before the iterator changes it was unsafe). The
machine performance is now back where it was. Without the patch
the performance regression was so bad, that the machine was unusable
even for simple editing (there were freezes each time the syncer
ran). Is it ok if I commit it, or do you have any better ideas?

[there is a missing part for zfs that I have not posted, but it is
 similar to the rest]

christos