On 23 May 2014, at 01:50, Christos Zoulas <christos%astron.com@localhost> wrote: > 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?). To access flags, yes. ffs_reclaim() changes v_data with interlock held. > 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, No, it is wrong in some parts. > or do you have any better ideas? Does the attached diff help? -- J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)
Attachment:
ffs_sync.diff
Description: Binary data