Agree with Chris, It has been shown that with DIRECTIO or CONCURRENT IO (depending on the file system you use) database performance differences between raw and FS devices are small or insignificant.
Actually, you have to be really careful. It is true that a filesystem with BOTH DirectIO and ConcurrentIO can perform nearly the same as raw partitions - HOWEVER - in many cases there are a lot of filesystem attributes - and skewed testing - that can throw the results one way or another. For example, in standard TPC style testing on Linux, we have proven that filesystem journaling - even at the default of journaling metadata - has a 400% impact on database throughput with low memory (e.g. a typical TPC has a lot of reads - which normally would be read from cache). I suspect the tests cited at the top were likely influenced by filesystem journaling - especially as his later tests didn't have quite the same order of magnitude and he attributed it to possibility of caching. From a read perspective - let's face it - DBMS caching and cache hit ratios of 98%+ makes most PIO problems almost a trivial discussion. Write operations also can be cached with the exception of the transaction log. Which leads to the obvious observation that filesystem journaling is kinda moot as most DBMS's have their own journal - we call ours a transaction log.
And then there is the true ConcurrentIO (aka CIO) tests. Very few filesystems support true CIO - Solaris UFS, Veritas VxFS, AIX JFS2, etc. are some of the few. AFAIK (and there are some that argue this but it can't be proven by the source code that I have seen), none of the Linux filesystems do (if someone could prove this one way or the other, it would be great - none of the toy tests I have seen do so as they allow a lot of variance). What true CIO means is NOT whether two different processes can write to the same file or not - but whether the filesystem implements any form of concurrency controls. With true CIO - there are *NO* concurrency controls at the file system. Repeat: NONE - ZERO - NADA - filesystem locking. If two apps try to update the exact same disk block - it is allowed. CIO assumes that the app will prevent writers from hitting the same blocks concurrently (ASE controls this via the MASS bits). Heavily single threaded tests as cited in that whitepaper from Dhimant would not hit this issue. However it can be a real peformance hit on systems which have fairly broad concurrency controls when multiple processes or threads are writing within the same area covered by a filesystem lock. For example, if two SPIDs in ASE are updating two different contiguous pages in a single page buffer pool and both are being written to disk. There are huge differences in speed with VxFS and AIX for example with CIO not enabled (can be done via mount options) and concurrent write activity....hence the recommendation to mount those filesystems with forcing CIO as a mount option. CIO, of course assumes DirectIO already (it cannot work with buffered files), so some suggest that CIO should be automatic whenever a file is opened with O_DIRECT... Now in order for CIO to be problem - or rather the lack of it - you have to find out what the filesystem locking granularity is....for example on extent based file systems - is it at the extent level....and if so and the extent is 16K, then it is moot issue for SAP apps as we default to 16K page size. And then you have to figure out when concurrent writes within the same locking granularity would happen (remember - ASE caches most writes until checkpoint or wash marker or HK Wash....and log is serialized, so not a problem there).
The real question is: if you can tune the filesystem by disabling journaling and possibly enabling CIO, whether the fun of managing raw partitions is worth the aggravation or not. The answer likely is no. File systems make it much easier to implement smaller database requirements such as master, sybsystemprocs, etc. or extend user databases without having to worry about mixing device fragments on devices with other databases (in case you want to move a database using mount/unmount - or use storage snapshots for backups) - etc. And for most systems - even if true CIO is not available - there will be little difference between filesystem vs. raw. On the flip side, we have never known a raw device problem to cause a machine crash....whereas filesystem problems (e.g. a filesystem panic) quite often will.....and clustered file systems just aren't there yet - so when using clusters - you just have to use raw.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.