On 29.12.11 01:04, Kirk McKusick wrote: > Rather than changing BKVASIZE, I would try running the cvs2svn > conversion on a 16K/2K filesystem and see if that sorts out the > problem. If it does, it tells us that doubling the main block > size and reducing the number of buffers by half is the problem. > If that is the problem, then we will have to increase the KVM > allocated to the buffer cache. > This does not make a difference. I tried on 32K/4K with/without journal and on 16K/2K all exhibit the same problem. At some point during the cvs2svn conversion the sycer starts to use 100% CPU. The whole process hangs at that point sometimes for hours, from time to time it does continue doing some work, but really really slow. It's usually between revision 210000 and 220000, when the resulting svn file gets bigger than about 11-12Gb. At that point an ls in the target dir hangs in state ufs. I broke into ddb and ran all commands which i thought could be useful. The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt The machine is still in ddb and i could run any additional commands, the kernel is from Attilio's vmcontention branch, which was MFCed yesterday, and updated after the MFC. The same problem happens on 9.0-RC3. If i run the same test on a zfs filesystem i don't see any problems. Florian
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:22 UTC