Yes, it did change the behavior to print ENOTSUP message if invalidation isn't supported (i.e. true on non Linux) for a block device. Nothing has changed other than printing it. I've also confirmed this, but what makes this confusing is that strerror(ENOTSUP) prints "Unknown error" on Cygwin. I'll send a patch to make this less confusing or just not print it on ENOTSUP. 2017-07-25 2:31 GMT+03:00 Jeff Furlong <jeff.furlong@xxxxxxx>: > Hi All, > Commit 22de5d7741f963e57dd5e3bb70d822e992dd2515 seems to have changed how Windows works with the default invalidate parameter. Previously it was not needed to specify invalidate=0, but now it is needed on Windows. Without it, fio reports: > > fio-2.21 > Starting 1 thread > fio: cache invalidation of \\.\PHYSICALDRIVE1 failed: Unknown error > fio: cache invalidation of \\.\PHYSICALDRIVE1 failed: Unknown error > > Is the expectation that Windows default invalidate (1) should silently ignore this issue, or must the user specify invalidate=0 on Windows platforms? Thanks. > > Regards, > Jeff > > -- > To unsubscribe from this list: send the line "unsubscribe fio" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html