In our system-administration tasks with Drupal, my team found a couple of issues related to how Drupal handles files that other users might find useful to know about. I do not have workarounds.

We found with both Drupal and our Java app server that symlinking the base installation directory can cause problems. When I installed Drupal in /var/www.drupal-6.8 but pointed Apache to symlink /var/www/drupal, I got intermittent white screens. The Java server was similar, it resolves to real paths in its auto-generated configurations and that caused us problems during upgrades.

Also, in Drupal, when you try to use "private files," it uses a path outside of the Drupal installation tree. Even though this is a feature of Drupal, it doesn't work reliably -- notably b0rking where themes look for files. This appears to be due to the code in Drupal's file.inc. In other words, it's a "feature."

Thus all methods for pointing to some other part of the filesystem than ~drupal/sites/[site]/files don't seem to work correctly in Drupal 6. In our environment, SAN storage is usually mounted to a top-level directory like /u1. For large-storage sites, the only solution would be to put the whole Drupal installation onto the SAN volume, not just the files directory. (Yuck)

For one project in my department, a developer used the Zend Download Optimizer to manage large file downloads. This required custom module development and also core changes that we found unsettling. That was the only way to work around PHP's limitations in large file handling.

I speculate that it might be possible to offload binary file handling directly to Apache through configuration to avoid Drupal mods entirely, though I suspect that would work for downloading but be very difficult to figure out for uploading, since Drupal needs to store info about the file.