Add Linux/NTFS to list of combinations that don't support direct I/O

[s-h-a-d-o-w]

Not sure whether you warn/fail when executing fio and that is the case but you do at least mention it here. And this combination is missing.

[sitsofe]

Well here's the thing: technically it IS supported in the Linux sense that it quietly falls back to buffered I/O rather than making fio throw an error right? And if this were ever changed how would we know?

[s-h-a-d-o-w]

Please note that there are two aspects that I wrote about - the possibility of throwing an error and mentioning this in the docs are two separate things. As far as the docs are concerned - couldn't your argument also be made about Open-BSD and Solaris? Maybe someday, it will be possible to use direct I/O with them?

[sitsofe]

couldn't your argument also be made about Open-BSD and Solaris

Those will cause errors to be thrown (and I can't see ZFS on Solaris ever supporting direct at this stage). On Linux you often don't get an error - it may just silently do something contrary to what you might expect so how can you tell you're in that case if there is a docs warning?

[s-h-a-d-o-w]

I'm not familiar with Linux' handling of I/O, so I don't know how often this is the case but it just seems dissatisfactory to me to leave it up to the user to figure out why they get weird numbers. Especially when there is basically zero information online like in this case. If there was at least some compatibility table somewhere, I could see how one might argue "It's right there, they just have to look it up".

Anyway - in the end, it's obviously your decision how to handle this, I just wanted to point out this unexpected and very puzzling behavior that almost had me give up, to spare others a similar experience.

[axboe]

We're talking about the in-kernel shipped ntfs driver? It doesn't set ->direct_IO at all, so IO should fail with EINVAL and fio should print its usual blurb about that.

[s-h-a-d-o-w]

I tried the following command on KDE neon useredition-20180802 using fio v3.8: fio --name=doesntmatter --ioengine=libaio --thread=1 --size=1024m --bs=128k --time_based=1 --runtime=5s --iodepth=32 --numjobs=1 --rw=read --direct=1 --startdelay=0s --filename=cdm

I executed it 5 times, the speeds from the results were: 2637, 2826, 2593, 2770 (For a SATA drive that does 550-570 MB/s in Windows)

Then on FAT32, I got the "real" numbers: 560, 560, 560, 560, 559

[sitsofe]

@s-h-a-d-o-w can you see which NTFS driver you're using? Should be visible in mount output...

[s-h-a-d-o-w]

This is what mount has to say about the partition. I hope it contains what you're looking for, since I'm not familiar with the names of the drivers:

/dev/sda2 on /media/neon/5AB88470B8844C87 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

[sitsofe]

I'm pretty sure that means you're using NTFS-3g via FUSE. You can probably use lsblk to confirm...

[sitsofe]

I don't think it's fair for the fio project to carry a "here's how direct I/O performs on filesystem X with configuration Y" compatibility table for (Linux) filesystems, especially given that anyone can create a FUSE based filesystem at any point (we'd need to record the versions etc). However, adding an additional warning to the documentation that "just because direct I/O was accepted by a Linux filesystem doesn't mean it is definitely bypassing the buffer cache" (ha!) might be helpful...

[sitsofe]

Labelling this one up as patcheswelcome because internally we don't have the manpower to get around to this one.