Hi, On 23 October 2017 at 11:02, Paolo Valente <paolo.valente@xxxxxxxxxx> wrote: > > in a time_based test with direct=0, a small file happened to be read several times. Yet I/O was actually done only when the file was read for the first time, even if invalidate was set. > > So, if I'm not mistaken, the buffer cache still builds up even if invalidate is set, right? Correct - invalidate just invalidates the cache at the "beginning" (see http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-invalidate ). See below where I agree with using your direct=1 suggestion if you want to avoid the cache. See http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-direct for documentation on direct. > Then, in a time_based test, the only way to make sure that I/O is constantly done, is to use direct=1, isn't it? Of course, unless the file is so large that one knows that no portion of the file will be found in the buffer cache when read again. If you mean "the only way for fio to try and avoid all I/O being cached/being only serviced by Linux's buffer cache is to use direct=1" then yes. Also as you suggest you can do I/O over a region big enough that a significant amount of I/O must not be cacheable therefore the average speed would better reflect that of the underlying disk (that's why you hear the old bonnie benchmark rule that you had to use a file size at least twice memory etc as it had no cache bypass mode). If you do a lot of I/O to only a small region then this is clearly still cachable though. -- Sitsofe | http://sucs.org/~sits/ -- 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
