Michal Mertl wrote: > I'm now unable to make it dead-lock again. Yet it happened quite easily. I > had more md backing files in the same directory at the beginning (to test > Terry's suspicion mentioned in thread 'jail' on hackers@). > > After the first lock-up I tried 'while(1);tar xzf ports.tgz; rm -rf > ports;end' on normal filesystem, let it run for long time (> 1h) and then > I found the system almost dead-locked too (the system worked, but anything > accessing disk was painfully slow - it might be the same problem or it > might be different. It never ended (at least for > ~30 mins when I didn't > (weren't able) anything on it). syncer and bufdaemon and others were in > wdrain. Disk as seen in systat -v showed maximal usage yet no inodes were > resolved. Sometimes during that test I had lock order reversal:
Hmm. This isn't actually the same, I think. This is just the point at which you have run out of available memory to maintain additional dependencies, and giant held. The key to this diagnosis is that you "let it run for a long time" before it "locked up". The deadlock condition requires that two people do directory traversals at the same time in vnode backed files in the same directory. It has to do with the locks on the backing files as a result of root vnode traversal vs. the backing vnode in the parent directory. I haven't characterized it better than that. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
