ProductsDesktop Server Red Hat Enterprise Linux OpenStack Platform For IBM POWER For IBM System z For SAP Business Applications Red Hat Satellite Management For Scientific ComputingExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportAccelerate Automate Integrate Red Hat JBoss Developer Studio Portfolio Edition Web Framework Kit Application Platform Web Server Data Grid Portal Fuse Red Hat JBoss A-MQ SOA Platform BRMS Data Services Platform JBoss Operations Network JBoss Community or JBoss enterprise
SolutionsWhy Red Hat Why open hybrid cloud? The new IT Public cloud Cloud resource library Private cloud Infrastructure-as-a-Service (IaaS) Platform-as-a-Service (PaaS) Cloud applications and workloadsSolaris to Red Hat Enterprise Linux Migration overview Migrate from your UNIX platform How to migrate to Red Hat Enterprise Linux Upgrade to the latest Red Hat Enterprise Linux release JBoss Enterprise Middleware Benefits of migrating to Red Hat Enterprise Linux Migration services Start a conversation with Red Hat
TrainingClassroom training Red Hat Online Learning Virtual training Remote classroom training On-site team training Online Learning LabsPopular and new courses Red Hat JBoss Administration curriculum Core System Administration curriculum Red Hat JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing, Virtualization, and Storage curriculum
ConsultingSOA and integration Business process management Cloud and Virtualization Custom Software Development Enterprise Data and Storage Systems management Migrations
Table of contents
Choosing elevator settings
Most Linux block device drivers use a generic tunable "elevator" algorithm for scheduling block I/O. The /sbin/elvtune program can be used to trade off between throughput and latency. Given similar loads, the ext3 file system may require smaller latency numbers as provided to the /sbin/elvtune program in order to provide similar results to the ext2 file system.
In some cases, attempting to tune for maximum throughput at the expense of latency (in this case, large read latency (-r) and write latency (-w) numbers used with the /sbin/elvtune program) can actually decrease throughput while increasing latency. This effect is more pronounced with the ext3 file system for a variety of reasons.
In order to tune for our default file system choice of ext3, Red Hat has reduced the default read and write latency numbers to half of the default values (from 8192 read, 16384 write to 4096 read, 8192 write). We expect that in general use, you will not have to change these numbers; we hope we have already done this for you. Our changed default values have produced good results in our tests. However, in order to tune for specific applications, we suggest benchmarking your applications with a variety of values, testing interactive response during some runs if interactive response is important to you. In general, we recommend that you set read latency (-r) to half of write latency (-w).
For example, you might run:
Once you have found elvtune settings that give you your most satisfactory mix of latency and throughput for your application set, you can add the calls to the /sbin/elvtune program to the end of your /etc/rc.d/rc.local script so that they are set again to your chosen values at every boot.
Red Hat is continuing to work on several performance enhancements to ext3, so you can expect several of these cases to improve in the future. This means that if you choose data=writeback now, you may want to retest the default data=ordered with future releases to see what changes have been made relative to your workload.
If the system crashes during such an extend in data=ordered mode, then the data blocks may have been partially written, but the extend will not have been, so the incompletely-written data blocks will not be part of any file.
The only way to get mis-ordered data blocks in data=ordered mode after a crash is if a program was overwriting in the middle of an existing file at the time of the crash. In such a case there is no absolute guarantee about write ordering unless the program uses fsync() or O_SYNC to force writes in a particular order.