: : :--bp/iNruPH9dso1Pn :Content-Type: text/plain; charset=us-ascii :Content-Disposition: inline : :I configured a vnode-backed md and enabled swapping on it. A few :hours later after moderate swap use the console showed: : :swap_pager: indefinite wait buffer: bufobj: 0, blkno: 889347, size: 8192 :[...repeated...] : :The backing store was a sparse file, but there was ample space: This is likely your problem. Do NOT use a sparse file for file-backed swap. If you carefully backtrace the other processes on the stuck system I'll bet you will find one stuck in ffs_balloc (or similar) in addition to the one you found stuck in allocbuf(). If you do, then its the same bug I reported to Kirk not too long ago. I determined that there was a lock order reveral between the locking of indirect blocks (on files) and related data blocks. It turns out that the data block must always be locked first because the standard BMAP path holds a locked data block while resolving the indirect block. However, when a dirty VM page is written to sparse file backing store the indirect block winds up being locked before the data block. It's only a problem when a VM fault has to allocate the underlying filesystem block (in our case, rtorrent was read()ing directly into a memory mapped sparse file). In anycase, the fix for FFS is /usr/src/sys/vfs/ufs/ffs_balloc.c:1.12 in the DragonFly source tree. I believe that may fix your swap issue as well, but my first comment still stands: Do NOT ever use a sparse file for swap backing store. Massive fragmentation within the file will occur and if the machine swaps regularly then after a while it will no longer be able to optimize swap I/O and will be even MORE sludgy then the normal sludginess you get when you have to page to swap. -Matt Matthew Dillon <dillon_at_backplane.com>Received on Tue Sep 13 2005 - 20:00:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:43 UTC