If you use InnoDB and have long-running select statements then the InnoDB undo space can grow large because purge can't advance beyond the longest open transaction. If this is blocked for too-long then pages to be purged might leave the InnoDB buffer cache and the purge thread will have to do many disk reads. As the InnoDB purge process is single-threaded it might not be able to catch up and a server can use too much disk space for a very long time.
I experienced this problem at work. I modified innochecksum to report the number of pages by type and it was easy to see that undo accounted for most of the ibdata1 file (a few hundred GB). As InnoDB doesn't shrink ibd files there is no way to get this space back on a running server but I would like to prevent the problem in the future.
The problem was solved by using the multi-threaded purge patch from XtraDB for MySQL 5.1. The patch isn't too much code so I felt comfortable testing it and was able to review it. Since deploying it I no longer have to worry about servers using too much space for undo because of purge lag.