fio基础25

8.0 Trace file format --------------------- There are two trace file format that you can encounter. The older (v1) format is unsupported since version 1.20-rc3 (March 2008). It will still be described below in case that you get an old trace and want to understand it. In any case the trace is a simple text file with a single action per line. 8.1 Trace file format v1 ------------------------ Each line represents a single io action in the following format: rw, offset, length where rw=0/1 for read/write, and the offset and length entries being in bytes. This format is not supported in Fio versions => 1.20-rc3. 8.2 Trace file format v2 ------------------------ The second version of the trace file format was added in Fio version 1.17. It allows to access more then one file per trace and has a bigger set of possible file actions. The first line of the trace file has to be: fio version 2 iolog Following this can be lines in two different formats, which are described below. The file management format: filename action The filename is given as an absolute path. The action can be one of these: add Add the given filename to the trace open Open the file with the given filename. The filename has to have been added with the add action before. close Close the file with the given filename. The file has to have been opened before. The file io action format: filename action offset length The filename is given as an absolute path, and has to have been added and opened before it can be used with this format. The offset and length are given in bytes. The action can be one of these: wait Wait for 'offset' microseconds. Everything below 100 is discarded. The time is relative to the previous wait statement. read Read 'length' bytes beginning from 'offset' write Write 'length' bytes beginning from 'offset' sync fsync() the file datasync fdatasync() the file trim trim the given file from the given 'offset' for 'length' bytes 9.0 CPU idleness profiling -------------------------- In some cases, we want to understand CPU overhead in a test. For example, we test patches for the specific goodness of whether they reduce CPU usage. fio implements a balloon approach to create a thread per CPU that runs at idle priority, meaning that it only runs when nobody else needs the cpu. By measuring the amount of work completed by the thread, idleness of each CPU can be derived accordingly. An unit work is defined as touching a full page of unsigned characters. Mean and standard deviation of time to complete an unit work is reported in "unit work" section. Options can be chosen to report detailed percpu idleness or overall system idleness by aggregating percpu stats. 10.0 Verification and triggers ------------------------------ Fio is usually run in one of two ways, when data verification is done. The first is a normal write job of some sort with verify enabled. When the write phase has completed, fio switches to reads and verifies everything it wrote. The second model is running just the write phase, and then later on running the same job (but with reads instead of writes) to repeat the same IO patterns and verify the contents. Both of these methods depend on the write phase being completed, as fio otherwise has no idea how much data was written. With verification triggers, fio supports dumping the current write state to local files. Then a subsequent read verify workload can load this state and know exactly where to stop. This is useful for testing cases where power is cut to a server in a managed fashion, for instance. A verification trigger consists of two things: 1) Storing the write state of each job 2) Executing a trigger command