Separate from the main topic, your problem with session files overrunning the server seems to be experienced by quite a few folk... and I suspect the ones that haven't had a problem are oftentimes either lucky (in that they've not needed to think about it because of the way their code was (inadvertently) written- and wasn’t generating a lot/sizeable of session files more by accident than by design), or perhaps have reasonably high-end systems which helps hide the issue, or perhaps addressed it the American way (pretty much like you did) by simply getting a bigger hammer.
I have had my eye on my own session files from before your comment, but since then I've been monitoring them more closely (and although they're tiny, but they do seem to have been growing in number - concerning, because it's only my test traffic at the moment).
I've not looked into the details as yet, though, the impression I have gleaned- only in passing, whilst looking for other unrelated material- is that it may be more of a PHP garbage-collection issue than one with the CI framework (?)… and there may well be ways to address it on the PHP side (I’ve not looked into this).
That being said, the one place CI does permit some control over session data is in the App.php file: $sessionRegenerateDestroy, which is set to FALSE by default (perhaps there is a good reason for this default ?)... which I've changed to TRUE, with no apparent problems to my site, yet. This doesn't stop them from accumulating when users close their browsers without signing out, but it seems to have slowed the accumulation down a bit.
