For instance, when designing a new SAN architecture, and configuring dedicated backup volume for SQL for sequential I/Os will be appropriate; is the I/O pattern sent to the subsystem sequential in nature?
By default, yes LiteSpeed performs multi-threaded writes. All writes to any specific target device are always issued sequentially and in-order- however- they are issued such that they may be completed asynchronously. (out of order issuance is only possible due to IO error recovery) Yes- it is entirely possible to have multiple writes in flight (and likely as well).
By default, each thread can have 2 writes issued at any given moment. By default, each thread writes to the smallest file available. Consider a backup that uses 4 threads writing to 1 file. At any given moment it is theoretically possible to have 8 outstanding writes in-flight. Consider the same backup that is striping to 2 files- at any given moment, those 8 writes will be divided among both files- so closer to 4 although there is a little wiggle-room.
These defaults are all configurable. The number of outstanding writes is configurable via the @IOFlag parameter. @IOFlag=’overlapped=1’ will limit 1 outstanding write per thread. The manner that LiteSpeed writes to files is also configurable via the @IOFlag. @IOFlag=’thread_to_file=1’ will tie each thread to its corresponding stripe file. (thread_to_file=0 ties writing to the smallest file (and is the default), thread_to_file=2 will force each thread to round-robin among available stripes)
Consider the case where thread count = stripe count, and IOFlag=’overlapped=1’, @IOFlag=’thread_to_file=1’- This will dedicate each thread to one specific stripe and become synchronous… Or mix and match to create a variety of IO scheduling schemes.
