Exchange's database (the EDB files on disk) work together with what are known as transaction logs. It sounds to me as though these logs are stored on your R: drive. Every modification in and out of the database is written to a transaction log file first; at a later time, it is lazily written into the database file. Logs are cleared from disk only when an online Exchange-aware (very important) backup is made - an image of the server would not clear the logs, for example.
The intention is to have the database files and logs on totally separate RAID arrays. If you lose the array holding the databases, you can restore from backup and then replay the existing log files into the database. In this way you recover to within moments of the disaster. Logs are not a replacement to a backup, but a tool used in some disaster recovery scenarios - if the whole cluster blew up, you'd lose your logs and only have data back to the last backup anyway. In a properly designed system, the logging architecture can also offer some performance benefits, since logs are generally stored in faster spindles than databases and changes need not be written by the Store to the database immediately.
As noted above, filling your logging drive would cause databases to dismount. If nothing is available to log database changes to, Exchange is unable to operate as designed and dismounts databases as a result. The 75GB threshold mentioned is not a hard-and-fast requirement. However; you should be running regular Exchange-aware backups of your servers with a proper tool (Windows Server Backup, Backup Exec with Exchange agent, System Center Data Protection Manager etc.). The free space you require ultimately depends on how heavy the traffic is, the data in and out per day, how frequent the backups run to clear the logs, how long the backups take to run and so on.
There's a lot more available online if you need to read more:
http://www.msexchange.org/articles/Transaction-Logs-Lifeblood-Exchange.html.
-Matt
