> Il giorno 23 ott 2017, alle ore 20:26, Sitsofe Wheeler <sitsofe@xxxxxxxxx> ha scritto: > > 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 > ). Hi, thank you very much for answering this and my other question thoroughly! Maybe I would specify, in the description of invalidate, that the invalidation is not repeated in case the I/O on a file restarts from the beginning go the file. Thanks, Paolo > 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
