summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/exported-sql-viewer.py
diff options
context:
space:
mode:
authorKent Overstreet <kent.overstreet@linux.dev>2025-03-10 18:44:12 -0400
committerKent Overstreet <kent.overstreet@linux.dev>2025-07-01 12:44:45 -0400
commit92a6ac5b84d360fa1864182de2e6291c25a86d27 (patch)
tree32113dbcdc17d0092d1912b1d9e3ec093ce9df5c /tools/perf/scripts/python/exported-sql-viewer.py
parentcff9968c8ead1b5faf1b310d109f9cd1a78d0330 (diff)
block: Allow REQ_FUA|REQ_READ
FUA is also allowed with reads, not just writes. The specified behaviour is: - If the location being read from in the drive cache is dirty, it's flushed - Read is serviced from media, not cache It's documented in the NVME specification, and the nvme driver already passes through REQ_FUA for reads, not just writes, so there's no reason for the block layer to be disallowing it. To validate behaviour, a simple test was run on a variety of hardware that checks latency of repeated reads to the same location (cached reads), random reads (uncached), and FUA reads to the same location. Data: - Samsung consumer SSDs Reads appear to not be cached - Seagate SCSI hard drives (ST20000NM002D) Reads are cached, and FUA reads appear to work correctly Link: https://lore.kernel.org/linux-block/20250311133517.3095878-1-kent.overstreet@linux.dev/ Link: https://lore.kernel.org/linux-bcachefs/26585.34711.506258.318405@quad.stoffel.home/T/#m5fffbc0e1c68cf0479c94b9f4ac1bef297333782 Cc: Jens Axboe <axboe@kernel.dk> Cc: linux-block@vger.kernel.org Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Diffstat (limited to 'tools/perf/scripts/python/exported-sql-viewer.py')
0 files changed, 0 insertions, 0 deletions