This reminded me of a bug on NetApp where file systems that are near full had their performance drop significantly (like half). (admittedly that was a few years ago).
The answer as everyone said is it depends, but it is worth thinking it through.
The main downside of full file systems is the list of free inodes are likely to be fragmented and all over the place.
There are three types of data that sit on the hard disk for a database.
- Your actual database file. This will be a large preallocated file that generally grows in large chunks (10% for example).
- Logs, your transaction log that is being continuously written to, deleted, written to, etc...
- Temporary files for large queries that cannot run in memory.
(1) only needs free space when allocating more space for your file set. If your database is not growing it should be unaffected by a low disk space file system.
If it is allocating though, it could ask for a very large chunk that doesn't fit into any free list you have immediately fragmenting your database and causing seeking when it needs data to ready into memory.
(2) a naive impelementation of logs where it uses the OS to manage allocating space and deleting it will suffer. Assuming your database is not read only, there will be a constant stream of logs, they will frequently be fragmented on a low hard disk space. Ultimately this will hurt your write performance.
(3) tempDB, if the DB needs it for shoddy written queries, or not enough RAM, then you've got bigger problems than low disk space causing performance problems as even your read performance could become disk bound then. You also run the risk of an outage if MySql needed to allocate disk space for tempDB and the hard disk ran out.
About backups...
- Every enterprise I have worked in keeps backups on the same machine. When it comes to a restore (who cares about backups, it's the restores that count). Nothing is going to beat the speed of having the db file right there on the same disk.
- Hopefully obvious, ensure the backups are not just local.
In short I'd say you'll survive providing your DB is not write heavy. If it is, then low disk space is a problem. But if I was you I'd work on the following sooner rather than later.
- Confirming I have enough RAM
- Segregating logs and all transient data from your DB.
- Segregating your OS, your MySql install from the remainder.
Use separate spindles and controllers if you can for 1.
Followed by separate spindles
Followed by a poor man's separate partitions.