Register Login
Python Photoshop SAP Java PHP Android C++ Hadoop Oracle Interview Questions Articles Other

Difference between Raw Partitions, File Systems, Dsync and Quick I/O

Updated May 18, 2018

Explain some differences and recommendation for Raw Partitions, File Systems, Dysnc and Quick IO on SAP ASE?

SOLUTION

Below listed is the summary of the different Linux file system devices and how they operate with ASE.

Understanding Raw Partitions

  • Raw partitions in Linux are not present in the kernel. These have been removed around the 2.6.3 timeframe.
  • RedHat and SuSE / Novell Support back ported the support.
  • These were supported by either /etc/rawdevices file or a udev rule (latter preferred).
  • The DSYNC parameter was especially implemented for Linux.
  • The preference for Linux developers is using the O_DIRECT (direct I/O) to a file. However, we also prefer async I/O too.
  • The user has to understand that raw partitions will be removed by RH / SuSE in the future eventually. .

Understanding Ext2 File Systems

  • EXT2 was the default file system on Linux, for a longer period.
  • incase file system is large and comprises of lots of files (or is relatively full), fsck ("file system consistency check") times can be very long, therefore it does not offer journaling.
  • fsck will verify the empty space, even if an EXT2 files system is empty.
  • Early Sybase on Linux used this file system type, or alternatively used EXT3 with journaling has been disabled.
  • Linux will automatically function a full fsck if:
    • Its been mounted ~28 times
    • Host crashes hard.
    • Its been ~130 days since last full fsck.
    • File system does not amount cleanly.

Understanding Ext3 File Systems

  • For most enterprise Linux installations, this was the default file system.
  • Accepted into 2.4 kernel branch (a long time ago).
  • Default file system for RHEL 4, 5 and SLES 11.
  • SLES 10 defaults to ReiserFS (don’t use this! Choose something else).
  • This is considered safe, stable, and has been well tested.
  • The main advantage of EXT3 over EXT2 is that it adds journaling.
  • The user can do an in-place upgrade from EXT2 to EXT3.
  • Early ASE on Linux documentation said to use EXT3 with no journaling, as it adds overhead, and also negatively affects performance.

Understanding Ext4 File Systems

  • Ext4 was developed as the successor to EXT3 and now is the most common configuration used for ASE.
  • This is considered the link betweenEXT3 and btrfs.
  • Supports much larger file systems (1EiB) and files (16TiB).
  • For space this utilizes extents vs block mapping.
  • Persistent pre- and delayed- allocation.
  • For databases this is extremely GOOD. 
  • EXT4 pre-allocates space on the file system (vs writing all 0s first), and its likely that the space will be contiguous on the file system as well (reducing fragmentation).
  • Improved fsck times.
  • fsck skips checking the empty extents incase the file system has a lot of empty space.
  • journaling should be turned OFF, for an optimal ASE performance.

Understanding XFS File Systems

  • This was initially developed by SGI for IRIX in the early 1990s.
  • It was donated to the Linux kernel tree by SGI as part of their Linux move/adoption in 2000.
  • This is a Fully 64-bit, and considered to be very high performance.
  • Deletes were initially very slow, however, this has been resolved in later 2.6.3x kernel(s).
  • Journaling tweaks in later 2.6.3x kernels improves the performance equal to, or better than, EXT4.
  • XFS Caches aggressively in memory. Therefore, should not be used on low memory systems.

Disk Init: Understanding Dsync And Direct I/O

Within ASE, a database device can have the following attributes listed below:

1) Dsync: All writes to the database device occur synchronously.

  • This was initially released in ASE 11.9.2 (specifically for Linux) as the Linux kernel (at that time) did not provide support o the raw partitions, and ASE must guarantee writes to the underlying devices.
  • ASE's master device always has this attribute set on if its on a file system.
  • No, this cannot be changed.
  • Note: The first few MB of tempdb are on master, so this can impact the  tempdb performance!

2) Direct I/O use sdirect (asynchronous) I/O:

  • This is same as raw partitions. This is the default setting for disk init to a file system-based device in ASE 15.5 and above.
  • Neither direct i/o or asynchronous i/o, write directly to the file system buffer cache.

Why  SSE Perform So Much Faster When Setting Both Dsync And Direct I/O Off?

1) If you turn both off dsync and direct i/o, ASE will seem to run much faster. This is due to the fact that all the writes are going directly to the file system buffer cache, and not committed immediately to disk.

2) The problem for ASE with UNCOMMITTED buffer cache writes: incase your host crashes, you are on your own. The data never makes it from cache to ASE.

3) Please keep in mind that while performance may be excellent for a while, things may come to a halt fast! This is all because the file system buffer cache either:

4) Therefore: DO NOT run ASE with both dsync and direct I/O turned off!

  • Filled and was flushed to disk (pdflush) or
  • A certain amount of time has already passed and the OS automatically flushed the file system buffer cache to disk (pdflush).

Direct I/O Considerations

Ase Quick I/O

  • Whether the user is using Veritas Quick I/O files, or regular (not Quick I/O) Veritas files: DO NOT use Sybase's Direct I/O. This is due to the fact that VxFS does not support ASE's implementation (using the directio parm) of Direct I/O.
  • Veritas's implementation of Quick I/O is the same thing as ASE's directio parm.

How Quick I/O Works

  • The Quick I/O product entails a character-mode device driver and a file system namespace mechanism. Files names tagged for Quick I/O are all recognized by the VERITAS file system (VxFS) and then converted to raw-mode device opens.
  • On the first access, a pseudo-device is created for representing the file. It is given the major number of the Quick I/O driver and a minor number which identifies the specific file.
  • The Quick I/O driver and VxFS coordinate for ensuring that the block map for the file is stable and is made available to the Quick I/O driver.
  • The file system will not attempt to reference the file without coordination with the Quick I/O driver. These measures provide for efficient raw mode file access,while providing correct file access semantics when the file is accessed with a read or write system call.
  • When utilizing a file accessed via the Quick I/O interface, ASE is not required to deal with the UNIX buffered write issue, and the file system cache is not utilized. Further, there is no duplication of data. Rather, data is moved directly between the application buffer and the disk without double-copying the data. The database accesses the database files as if they were raw volumes, yet the database administrator handles them as if they were regular files.
  • Therefore, if user needs direct i/o capabilities when using a VxFS file system for ASE, use Quick I/O.
  • there are no additional settings required on the ASE side, when Quick I/O is implemented for use by an ASE file system.
  • However, if user tries to set ASE's directio parm on a VxFS device (even if he is not using Quick I/O) he will receive an error saying "Inappropriate ioctl for device". The error message is actually a warning, in the sense that it is saying that the VxFS file system doesn’t support ASE's direct i/o implementation.

Recommended Posts:
×