BLKPARSE(1)
π¦ BLKPARSE(1) β the manual page, but make it cute π¦
okay bestie, buckle up π this is blkparse from section 1 of the manual, and she is that girl. Let's get into it.
β¨ NAME β¨
blkparse β produce formatted output of event streams of block devices π
πΈ SYNOPSIS πΈ
blkparse [ options ]
π DESCRIPTION π
okay so the blkparse utility is literally out here trying to combine streams of events for various devices on various CPUs, and then produce a formatted output of the event information. Specifically? It takes the (machine-readable π) output of the blktrace utility and converts it to a nicely formatted, human-readable form. it's giving translator. it's giving glow up. β¨
as with blktrace, some details concerning blkparse will help in understanding the command line options presented below. no cap.
- By default,
blkparseexpects to run in a post-processing mode β one where the trace events have been saved by a previous run ofblktrace, andblkparseis combining event streams and dumping formatted data. πΎ
blkparse may be run in a live manner concurrently with blktrace by specifying -i - to blkparse, and combining it with the live option for blktrace. An example would be:
% blktrace -d /dev/sda -o - | blkparse -i -
- You can set how many
blkparsebatches event reads via the-boption β the default is to handle events in batches of 512. π’ - If you have saved event traces in
blktracewith different output names (via the-ooption toblktrace), you must specify the same input name via the-ioption. no skipping this one bestie. - The format of the output data can be controlled via the
-for-Foptions β see OUTPUT DESCRIPTION AND FORMATTING for details. π
By default, blkparse sends formatted data to standard output. This may be changed via the -o option, or text output can be disabled via the -O option. A merged binary stream can be produced using the -d option. π
π OPTIONS π
-Ahex-mask /--set-mask=hex-maskβ Set filter mask to hex-mask, seeblktrace(8) for masks π-amask /--act-mask=maskβ Add mask to current filter, seeblktrace(8) for masks-Ddir /--input-directory=dirβ Prepend dir to input file names-bbatch /--batch={batch}β Standard input read batching-ifile /--input=fileβ Specifies base name for input files β default isdevice.blktrace.cpu.
As noted above, specifying -i - runs in live mode with blktrace (reading data from standard in). π«Ά
-Ftyp,fmt /--format=typ,fmtβ Sets output format (See OUTPUT DESCRIPTION AND FORMATTING for details.)-ffmt /--format-spec=fmtβ Sets output format (See OUTPUT DESCRIPTION AND FORMATTING for details.)
The -f form specifies a format for all events.
The -F form allows one to specify a format for a specific event type. The single-character typ field is one of the action specifiers described in ACTION IDENTIFIERS. π₯
-M/--no-msgsβ When-dis specified, this will stop messages from being output to the file. (Can seriously reduce the size of the resultant file when using the CFQ I/O scheduler.)-h/--hash-by-nameβ Hash processes by name, not by PID-ofile /--output=fileβ Output file-O/--no-text-outputβ Do not produce text output, used for binary (-d) only-dfile /--dump-binary=fileβ Binary output file-q/--quietβ Quiet mode π€«-s/--per-program-statsβ Displays data sorted by program-Sevent /--sort-program-stats=eventβ Displays each program's data sorted by program name or io event, like Queued, Read, Write and Complete. When-Sis specified the-swill be ignored. The capital lettersQ,R,W,Cstand for KB, thenq/r/w/cstand for IO. π
If you want to soct programs by how many data they queued, you can use:
blkparse -i sda.blktrace. -q -S Q -o sda.parse
-t/--track-iosβ Display time deltas per IO-wspan /--stopwatch=spanβ Display traces for the span specified β where span can be:- end-time β Display traces from time 0 through end-time (in ns)
- or
- start:end-time β Display traces from time start through end-time (in ns).
-v/--verboseβ More verbose marginal on marginal errors-V/--versionβ Display version β
π TRACE ACTIONS π
The following trace actions are recognised:
C-- complete β A previously issued request has been completed. The output will detail the sector and size of that request, as well as the success or failure of it. βD-- issued β A request that previously resided on the block layer queue or in the i/o scheduler has been sent to the driver.I-- inserted β A request is being sent to the i/o scheduler for addition to the internal queue and later service by the driver. The request is fully formed at this time.Q-- queued β This notes intent to queue i/o at the given location. No real requests exists yet.B-- bounced β The data pages attached to this bio are not reachable by the hardware and must be bounced to a lower memory location. This causes a big slowdown in i/o performance π, since the data must be copied to/from kernel buffers. Usually this can be fixed with using better hardware β either a better i/o controller, or a platform with an IOMMU.M-- back merge β A previously inserted request exists that ends on the boundary of where this i/o begins, so the i/o scheduler can merge them together.F-- front merge β Same as the back merge, except this i/o ends where a previously inserted requests starts.M-- front or back merge β One of the above.G-- get request β To send any type of request to a block device, astruct requestcontainer must be allocated first.S-- sleep β No available request structures were available, so the issuer has to wait for one to be freed. π΄P-- plug β When i/o is queued to a previously empty block device queue, Linux will plug the queue in anticipation of future ios being added before this data is needed.U-- unplug β Some request data already queued in the device, start sending requests to the driver. This may happen automatically if a timeout period has passed (see next entry) or if a number of requests have been added to the queue.T-- unplug due to timer β If nobody requests the i/o that was queued after plugging the queue, Linux will automatically unplug it after a defined period has passed. β°X-- split β On raid or device mapper setups, an incoming i/o may straddle a device or internal zone and needs to be chopped up into smaller pieces for service. This may indicate a performance problem due to a bad setup of that raid/dm device, but may also just be part of normal boundary conditions. dm is notably bad at this and will clone lots of i/o. πA-- remap β For stacked devices, incoming i/o is remapped to device below it in the i/o stack. The remap action details what exactly is being remapped to what.R-- requeue β Put a request back on queue.
π OUTPUT DESCRIPTION AND FORMATTING π
The output from blkparse can be tailored for specific use β in particular, to ease parsing of output, and/or limit output fields to those the user wants to see. The data for fields which can be output include:
aβ Action, a (small) string (1 or 2 characters) β see table below for more detailscβ CPU idCβ Commanddβ RWBS field, a (small) string (1-3 characters) β see section below for more detailsDβ 7-character string containing the major and minor numbers of the event's device (separated by a comma).eβ Error valuegβ Cgroup identifier of the cgroup that generated the IO. Note that this requires appropriate kernel support (kernel version at least 4.14).mβ Minor number of event's device.Mβ Major number of event's device.nβ Number of blocksNβ Number of bytespβ Process IDPβ Display packet data β series of hexadecimal valuessβ Sequence numbersSβ Sector numbertβ Time stamp (nanoseconds)Tβ Time stamp (seconds)uβ Elapsed value in microseconds (-tcommand line option)Uβ Payload unsigned integerzβ The absolute time, as local time in your time zone, with no date displayed
Note that the user can optionally specify field display width, and optionally a left-aligned specifier. These precede field specifiers, with a '%' character, followed by the optional left-alignment specifier (-) followed by the width (a decimal number) and then the field.
Thus, to specify the command in a 12-character field that is left aligned:
-f "%-12C"
π ACTION IDENTIFIERS π
The following table shows the various actions which may be output:
Aβ IO was remapped to a different deviceBβ IO bouncedCβ IO completionDβ IO issued to driverFβ IO front merged with request on queueGβ Get requestIβ IO inserted onto request queueMβ IO back merged with request on queuePβ Plug requestQβ IO handled by request queue codeSβ Sleep requestTβ Unplug due to timeoutUβ Unplug requestXβ Split
π§ RWBS DESCRIPTION π§
This is a small string containing at least one character ('R' for read, 'W' for write, or 'D' for block discard operation), and optionally either a 'B' (for barrier operations) or 'S' (for synchronous operations).
β DEFAULT OUTPUT β
The standard header (or initial fields displayed) include:
"%D %2c %8s %5T.%9t %5p %2a %3d"
Breaking this down:
%Dβ Displays the event's device major/minor as:%3d,%-3d.%2cβ CPU ID (2-character field).%8sβ Sequence number%5T.%9tβ 5-character field for the seconds portion of the time stamp and a 9-character field for the nanoseconds in the time stamp.%5pβ 5-character field for the process ID.%2aβ 2-character field for one of the actions.%3dβ 3-character field for the RWBS data.
Seeing this in action:
8,0 3 1 0.000000000 697 G W 223490 + 8
[kjournald]
The header is the data in this line up to the 223490 (starting block). The default output for all event types includes this header. π«Ά
π DEFAULT OUTPUT PER ACTION π
okay bestie this is the part where we find out what each action letter actually prints when it hits your terminal. every action has its own lil glow-up, so let's go one by one π
Cβ complete β if there's a payload, it shows up in parenthesis right after the header, and then the error value comes after it.
if there's no payload, you get the sector and the number of blocks (with a + chillin' between them, obvi). and if you passed -t, then the elapsed time shows up too. either way, the error value for the completion is the last thing you see. periodt.
Bβ bounced β no extra deets, she's just out here bouncing πDβ issued β issued, that's the whole vibe β¨Iβ inserted β inserted, mwah πQβ queued β if a payload is present, you get the number of payload bytes, then the payload in hexadecimal wrapped in parenthesis.
if there's no payload, it's sector + number of blocks. and if -t was specified, the elapsed time shows up (in parenthesis, cute). either way it ends with the command tied to the event, surrounded by square brackets. π
Fβ front merge β mergin' from the front, slayGβ get request β grabbing that request bestieMβ back merge β mergin' from the back, also slaySβ sleep β starting sector and number of blocks (with that+between them, as always), followed by the command tied to the event, in square brackets. π΄Pβ plug β just the command tied to the event, surrounded by square brackets. that's it, that's the whole post. πUβ unplug β unplugged, bye π«Tβ unplug due to timer β the command tied to the event (square brackets, natch) comes out, followed by the number of requests outstanding. β°Xβ split β the original starting sector comes first, then the new sector (separated by a slash/), and then the command tied to the event in square brackets. splitting is giving main character energy fr fr. βοΈAβ remap β sector and length get printed, along with the original device and the sector offset. remapped and thriving π¦
πΈ EXAMPLES πΈ
want to trace the i/o on the device /dev/sda and pipe it straight into human-readable form? bestie, say less:
% blktrace -d /dev/sda -o - | blkparse -i -
(peep blktrace (8) if you want the full lore on that one).
and guess what β the same behaviour can be achieved with the convenience script btrace. so this:
% btrace /dev/sda
has exactly the same effect as the command above. iconic. see btrace (8) for more. π
now if you wanna trace the i/o on a device and save the output for later processing with blkparse, use blktrace like this:
% blktrace /dev/sda /dev/sdb
this will trace i/o on /dev/sda and /dev/sdb and save all the recorded info into the files sda and sdb in the current directory β one for each device, respectively. and then later you can parse that trace information with blkparse:
% blkparse sda sdb
which will output the previously recorded tracing information in human readable form to stdout. chef's kiss πβ¨
π AUTHORS π
blkparse was written by Jens Axboe, Alan D. Brunelle and Nathan Scott. and this man page was created from the blktrace documentation by Bas Zoetekouw. absolute legends, all of them π«Ά
π REPORTING BUGS π
found a bug? don't be shy, report it to <linux-btrace@vger.kernel.org> β the maintainers wanna hear it fr fr π
β COPYRIGHT β
Copyright Β© 2006 Jens Axboe, Alan D. Brunelle and Nathan Scott.
this is free software. you may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. there is NO WARRANTY, to the extent permitted by law. (yes that's the dramatic part, take it seriously π)
this manual page was created for Debian by Bas Zoetekouw. it was derived from the documentation provided by the authors and it may be used, distributed and modified under the terms of the GNU General Public License, version 2.
on Debian systems, the text of the GNU General Public License can be found in /usr/share/common-licenses/GPL-2. π
π¦ SEE ALSO π¦
btrace (8)blktrace (8)verify_blkparse (1)blkrawverify (1)btt (1)
and that's a wrap on BLKPARSE(1) bestie π this page came from blktrace git-20070306202522, dated March 6, 2007 β yeah she's vintage but she still eats π
β¨ go forth and parse, you've got this π«Άπ
π¦ where this page comes from
- centos-stream 10: blktrace 1.3.0-13.el10 Β· GPL-2.0-or-later
- debian trixie: blktrace 1.3.0-0.2 Β· GPL-2.0-or-later
- fedora 43: blktrace 1.3.0-13.fc43 Β· GPL-2.0-or-later
- fedora 44: blktrace 1.3.0-15.fc44 Β· GPL-2.0-or-later
- nixos 26.05: blktrace 1.3.0
- nixpkgs unstable: blktrace 1.3.0
- opensuse-leap 16.0: blktrace 1.3.0+git.20211021-160000.2.2 Β· GPL-2.0-only
- opensuse-leap 16.0: blktrace 1.3.0+git.20211021-160000.2.2 Β· GPL-2.0-only
- opensuse-leap 16.0: blktrace 1.3.0+git.20211021-160000.2.2 Β· GPL-2.0-only
- opensuse-leap 16.0: blktrace 1.3.0+git.20211021-160000.2.2 Β· GPL-2.0-only
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms