File system or raw partition?

When deciding whether to use file systems or raw partition devices, there are a number of factors you should consider, such as operating system file system implementation, application I/O profiles, available operating system resources such as memory and CPU, operating system tuning for file system cache limits, and swapping preferences.

For earlier releases of Adaptive Server, file system devices were good for large read operations where the file system read-ahead outpaced Adaptive Server asynchronous prefetch capabilities, however, raw partitions performed better for write activity, particularly in high concurrency environments.

Adaptive Server 12.0 included the device dsync parameter, which implemented dsync I/O for file system devices, enabling updates to the device to take place directly on the storage media, or buffering them with the UNIX file system. Although it may have appeared that dsync bypassed the file system buffer to ensure recoverability, it still used the file system buffer, but forced a flush after each file system write. This double buffering in both Adaptive Server and the file system cache—plus the flush request—caused slower response times for writes to file system devices than for raw partitions.

Adaptive Server 15.0, includes the directio parameter for disk init, disk reinit, and sp_deviceattr, which implements direct I/O, improving the slower write times by allowing you to configure Adaptive Server to transfer data directly to disk, bypassing the operating system buffer cache. These platforms support the directio parameter:

Sun Solaris
IBM AIX
Microsoft Windows

Considerations before using directio

Consider the following before you use directio:

You may have to tune your operating system kernel, mount the file system with special options (for example, the forcedirectio mount option on Solaris), and make sure the operating system patch levels are sufficient for a high volume of direct I/O activity.
The directio and dsync parameters are mutually exclusive. If you are currently using the dsync parameter, but you want to use directio, you must first disable the dsync parameter, enable directio. However, changing a device attribute requires that you restart Adaptive Server.
Make sure that the memory requirements for file system caching and CPU requirements for changes in operating system processing for I/O requests do not affect the Adaptive Server resources.
Test how your application scales for user loads of 25%, 50%, 75%, and 100% before you switch a device from using raw, dsync, or direct I/O. By testing for each of these scenarios, you can see if the scaling is linear or degrades as the use load gets closer to 100%. If performance flattens at a point, but you still need to increase the user load because of increased user population, you may need to add more resources to Adaptive Server.
If you are running Adaptive Server with tempdb on a file system on SMP hardware, you may get more benefit from enabling directio than disabling dsyncio. However, test your applications at a variety of load levels with different tempdb device configurations. You may find that disabling dsyncio has a greater advantage on smaller SMP systems with lower user concurrency in tempdb or with fewer, but larger temporary tables, while enabling directio has a greater advantage on larger SMP systems or on systems with high concurrency in tempdb with smaller, but higher write activity, tempdbs. It may be beneficial to have one tempdb running with file system devices and dsyncio disabled for nightly batch reports, but to use raw partitions or file system devices with directio enabled, for the OLTP processing temporary databases during the day.

Enabling dsyncio may dramatically degrade query performance for sorting operations (for example, adding an order by clause to your query, or if you have dsyncio enabled for tempdb).

Generally, if you use sorting operations, disable dsyncio, or enable directio.

This example creates tempdb on a new device with dsyncio disabled:
```
USE master
Go
DISK INIT  name = 'tempdbdev01', physname = '/tempdb_data' , size = '4G', dsync = 'false'
Go
DISK INIT name = 'tempdblogdev01', physname = '/tempdb_log', size = '4G', dsync = 'false'
Go
ALTER DATABASE tempdb ON tempdbdev01 = '4G'  LOG ON tempdblogdev01 = '4G' 
Go
USE tempdb
Go
EXEC sp_dropsegment 'logsegment', 'tempdb', 'master'
go
EXEC sp_dropsegment 'system', 'tempdb', 'master'
go
EXEC sp_dropsegment 'default', 'tempdb', 'master'
go
```
If you already have devices established for tempdb, you need only to disable dsyncio, but you will need to restart Adaptive Server:
```
EXEC sp_deviceattr 'tempdbdev01', 'dsync', 'false'
Go
EXEC sp_deviceattr 'tempdblogdev01', 'dsync', 'false'
```