summaryrefslogtreecommitdiff
path: root/file.h
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2012-12-12 08:16:27 +0100
committerJens Axboe <axboe@kernel.dk>2012-12-12 08:16:27 +0100
commite6c4d732fc99070091367d0ce41fe2cf1ddd1dc9 (patch)
tree427a2de1b504fde8cf08f1da014e1234697edfd1 /file.h
parentd06ab917303f70289ad8f256c6e79a1eeee4bee4 (diff)
downloadfio-e6c4d732fc99070091367d0ce41fe2cf1ddd1dc9.tar.gz
fio-e6c4d732fc99070091367d0ce41fe2cf1ddd1dc9.tar.bz2
file hash: don't close file fd on lookup/add race
On Linux, udev often has a rule that triggers blkid to read data off the device, if the device has been opened for writing. This triggers when the device is closed. Fio has an internal file hash for lookup of files. When threads start, it can happen that one thread does a hash lookup without finding the file, but when it has opened the file and attempts to insert it into the hash, another thread has already completed that operation. When that race happens, fio closes the file handle and does the lookup again. That then triggers blkid to read pages off the device. As data in the cache is invalidated on open of the device, we know have page cache entries for the device again. This is a problem for unbuffered workloads, where the existance of page cache pages slows it down due to having to check for invalidation. The user observed problem is that fio exhibits bi-modal performance results, depending on whether the file hash race was hit during setup or not. Fix this by NOT closing the file if we hit this race, but instead wait until the file is closed after the run. Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'file.h')
-rw-r--r--file.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/file.h b/file.h
index 3024c544..11695e2f 100644
--- a/file.h
+++ b/file.h
@@ -65,6 +65,7 @@ struct fio_file {
void *file_data;
int fd;
+ int shadow_fd;
#ifdef WIN32
HANDLE hFile;
HANDLE ioCP;