Maybe this is cheating in terms of a blog post, but I wrote the bulk of this Support KB and wanted to share in as many ways as I could...
SharePoint 2010: Crawl process is stuck after SQL Server runs out of disk space http://support.microsoft.com/kb/2691203
Consider the following scenario:
You initiate a full/incremental crawl of the content source(s) in your SharePoint 2010 environment. Once the crawl begins, you find that the Crawl Store database (e.g. something such as 'SSA_CrawlStoreDB') for the Search Service Application (SSA) begins to grow causing the SQL Server to run out of disk space for either the database or transaction log directory. In this situation, the crawl will appear stuck in a 'Crawling' state. If an attempt is made to stop the crawl, the status will appear stuck in a 'Stopping' state. Additionally, in this disk starved state, the SQL Server may experience degraded performance (particularly if the disk space for TempDB is also impacted).
In this scenario, the crawl gets into a loop where the SQL Server attempts to allocate additional space for the applicable data or log directory. However, because there is insufficient disk space (or the destination does not allow for auto-growth), the space allocation will fail and the transaction for Search will be rolled back. The Search processes then attempt to repeat the failed transaction, which will continue to fail.
Attempting to stop the crawl (e.g. from the Search Admin page) could exacerbate the disk starvation problem (notably in large crawls) because this action could generate a potentially large number of transactions to delete items from the related crawl queue tables and "un-wind" the crawl process. As such, it is best to avoid stopping the crawl.
If the SQL Server runs out of space during a crawl, use the following steps to resume the crawl processing
For a side note not in the KB... If the transaction log was manually trimmed (e.g. files manually deleted) or if any of the stored procs for SP Search were manually rolled back, then your SP Search DBs are very likely out of sync. In this case, you'll unfortunately need to reset your index or restore all the SP Search DBs to a consistent point of time. Then, in regards to either case, start a full crawl.