On 22 May 2014, at 18:47, Christos Zoulas <chris...@astron.com> wrote:
> In article <2b9bf96f-5db2-4b91-8fd0-a01f0f455...@eis.cs.tu-bs.de>, > J. Hannken-Illjes <hann...@eis.cs.tu-bs.de> wrote: >> On 22 May 2014, at 13:27, Christos Zoulas <chris...@astron.com> wrote: >> >>> In article <0e8bfcfc-c4cd-4ce3-8bac-22eb8ebd3...@eis.cs.tu-bs.de>, >>> J. Hannken-Illjes <hann...@eis.cs.tu-bs.de> wrote: >>>> On 22 May 2014, at 03:15, Christos Zoulas <chris...@astron.com> wrote: >> <snip> >>> >>>>> - start a build >>>>> - hold a key down at the shell prompt and notice how it behaves >>>>> >>>>> Every 3 or so lines (of 80 characters), you'll notice a large pause >>>>> where the machine is unresponsive for a couple of seconds, and then >>>> comes back. >>>> >>>> I'm not able to reproduce this behaviour here. Please describe >>>> your setup (mounted file systems and build command) in more detail. >>> >>> The build command is standard. I have raid over sd0 (SAS drives). >>> How much memory do you have? Leave enough time for the buffer cache >>> to fill up. >> >> It is 16 CPU / 16 GB virtual machine on KVM/CentOS6. > > 8 real CPUs, no VM. > >> The output of "mount" and the raid level could help, any tuning >> with "sysctl"? > > No tuning. > > It worked fine before the changes... > > I am testing this now: > > http://www.netbsd.org/~christos/vnode_iterator.diff 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. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)