The SAN adds latency, which can be a problem for things like RDBMS commit where files are sync'd to media. Sometimes they just pretend it is on oxide and rely on battery backup, which might be OK, but be aware.
You can flow a lot of data per second in and out, but random might be a problem unless RAM cached. Some apps get more RAM caching by using mmap()/mmap64() to map files to VM -- no swap hit, just RAM or page fault to disk, which is how most OS do dynamic libraries and some OS have started doing this in kernel caching and inside standard library calls for all I/O. Huge random sets traversed once still run slow and waste RAM in the bargain, never mind SAN cache. If you have such latency problems, you may want to put those files on some sort of more local volume, even SSM. One way to have SAN backup is to have a hierarchical bit like the Sun ClientFS that backs all modified pages on the local disk to the SAN, using the local disk as a intermediate level cache. This handles larger volumes than most RAM budgets with less worry about right sizing, since you cannot run out of space on the local disk. The SAN load of backing it up can be tuned, so you do not have to write the same page twice if it gets only two mods close together.
However, while this solves random woes, for RDBMS commit sync, you may want either:
- a solid (not cache) local allocation (mirrored on two controllers, not RAIDN) striped fast disk or SSM for speed or
- to take the hit on sync to SAN, for low churn very random sets.
Luckily, many OS and RDBMS utilities, turned on or frequently applied, can optimize things so they are more often serial in a fast way, like range scans in an index or table scans in smaller tables. Be careful to apply them in the right order, as one might undo the other. Usually, RDBMS are on raw partitions, so there is no conflict; you just need to do both OS utilities for the non-raw and RDBMS utilities for their files/partitions. As I said, tricks like the APPEND table, or similar physical keying, ensure no holes and no churn of old pages, immediately or once defragged.
