What does sequential read write in fio means?

Question

Does sequential read write in fio (https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-readwrite) corresponds to the following rust code snippet below?

let mut file = File::open("10G.img").unwrap();
let mut writer = OpenOptions::new()
    .truncate(true)
    .create(true)
    .write(true)
    .open(format!("traditional_way.img.{}", i))
    .unwrap();

let mut buf = [0u8; 1024 * 1024];
let mut r = file.read(&mut buf).unwrap();
while r > 0 {
    writer.write_all(&buf[0..r]).expect("write file error");
    r = file.read(&mut buf).unwrap();
}

If it does, can I benchmark my sequential read-write on fio this way?

Note that 10G.img is a 10 GB size file that we want to read and write to another file location

fio --name=readandwrite --ioengine=sync --filename=/home/user/Desktop/examples/10G.img --iodepth=1 --rw=readwrite --bs=1024k --direct=0 --numjobs=1 --runtime=10 --time_based=1

Answer 1

(I think this just about squeaks by as a programing question but it really needs to reference fio's sync ioengine code which is readily available to read)

What does sequential read write in fio means?

It means fio will try and do a sequential read ;-) Exactly what happens depends on the options you pass to fio and the ioengine you use.

Does sequential read write in fio (https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-readwrite) corresponds to the following rust code snippet below?

Maybe but unfortunately you didn't include a concrete fio job file for this question so a random Stack Overflow passerby can't give a definitive yes or no. Depending on the command line options/job file that might be similar or it might be very different. I'm going to lean towards no because:

• What data is in your write buffer? By default fio is going to use pseudo-random data for writes so that you don't get a phoney benchmark result - benchmarking writes where the data is all zeros is a special case that can radically distort benchmarks. This is because some storage stacks have zero detection, others have have compression etc.
• Did you know the file truncation done by your Rust program may (depending on the filesystem) result in a sparse file? Reads from a sparse file may be abnormally fast and distort benchmarks because the filesystem can reply with large amounts of zeroes by just reading metadata and not having to really read the contents of the file. By default fio will try pre-allocate the file on Linux when doing reads so it doesn't suffer this particular pitfall...
• We don't know by just looking at your code what sort of batching your reads and writes have in Rust. You may find writes in Rust are being accumulated in a buffer before being sent to the kernel. You would have to something like strace on your Rust program to see what is actually being sent...
• Depending on how much RAM you have you may be just benchmarking the kernel's page cache in both the Rust and fio cases!
• Which bit of code are you going to time? fio tries to collect data on each I/O so it does more work than your Rust program does.

If it does, can I benchmark my sequential read-write on fio this way?

You can try but I there are questions about validity and usefulness of the results.

TLDR; Too many variables and assumptions make this question too vague to answer well... Maybe narrow the scope of your future questions to help get a better answer?