1. The order of file writes is guaranteed. This means that if the server says write A, then write B, the SAN/NAS guarantees that A is written to the physical medium before B. Additionally, on Windows, Microsoft guarantees that a call to SetEndOfFile(...) followed by FlushFileBuffers(...) is sufficient to force the file metadata to the physical medium. We require those same semantics to be respected by a SAN/NAS.

2. When a write request is issued in this environment, the write has actually been completed to the physical medium (not buffered by the operating system or the drive’s internal cache) when the SAN/NAS returns from the write call. This is generally true if point 1) above is enforced.

If the SAN/NAS does buffering, the order of the writes to the physical medium doesn't actually matter provided it absolutely guarantees that the file will always appear to have had all successfully completed writes applied to it even after a power loss. Typically, the "guarantee" is provided by a cache with battery backup.

ACCESSING A DATABASE FILE ON A STANDARD NETWORK SHARE

1. Database recoverability cannot be guaranteed because the network file link does not provide strong enough IO ordering semantics.
2. Any network error that occurs while the database server is trying to perform any IO operation will cause the engine to terminate with a fatal error.
3. If performance is a consideration, it is important to note that there is a huge performance penalty to pay for network IO versus local drive IO.