Skip to Content

SAP IQ 16.1, Redhat 7 and XFS - best practice, performance and journalling

Jun 01, 2017 at 01:54 PM


avatar image

Given XFS is the default file system for Redhat 7 and IQ 16.1 runs on Redhat 7.2 (or later), is there any best practice/configuration information anywhere (can't find any ?) for using XFS for SAP IQ 16.1 and any performance impact of using XFS vs EXT4 (we want to use files not RAW mainly for logistic reasons/integration with our own tools etc) ? In particular, earlier knowledge base articles (e.g. advise switch journaling OFF opn EXT4. Our understanding at the mo is that XFS does not support switching off journaling, would it have same issues as EXT4 does with journaling on and/or is there XFS tuning settings that would help (e.g use of external journals or other XFS settings) ? Are there any performance comparisons available for EXT4 (with journaling off) vs XFS (presumably with journaling on) ?

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Tom Kim
Jun 09, 2017 at 04:10 PM

If you do a web search on 'Linux EXT4 vs XFS' you will get some results but I didn't find any specifically mentioning database performance. Traditionally, Sybase/SAP did not & does not certify on, nor formally recommend any particular file system for its databases on Linux so customers could use anything they wanted. SAP does not formally test IQ/ASE/ASA on any particular file system because they were considered to be a part of the OS itself. SAP's engineering simply tests to make sure the database will run and install on the OS (which includes the file system choice) but not much else. That said, the following are some features of each you may want to consider:


  • Uses persistent pre- and delayed-allocation which is very good for databases because it will reduce your file initialization/expansion times
  • Pre-allocates space on the file system (vs writing all 0's first), and it's likely that the space will be contiguous on the file system as well (reducing fragmentation)
  • Has improved fsck times. If the file system has a bunch of empty space, fsck skips checking that empty space


  • Fully 64-bit, considered to be very high performance
  • Caches aggressively in memory which is the primary reason why its performance will be better. However, in the event of a system crash and there were some write operations in progress which did not make it out of the cache, your data will be compromised
  • Due to the aggressive caching, it's not recommended for low memory systems
10 |10000 characters needed characters left characters exceeded