Thanks again. One more query "maybe check how many I/Os the kernel sent to disk versus those that fio was asked to do" - For this can I rely on iostat or do you recommend any other tool? On Fri, May 22, 2020 at 9:34 PM Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: > > On Fri, 22 May 2020 at 10:01, Debraj Manna <subharaj.manna@xxxxxxxxx> wrote: > > > > Few queries for my understanding > > > > 1. Is there a way to bypass the disk/buffer cache while doing a fio > > test? I know about direct=1 but that does not always bypass a cache. > > Generally whether it will or won't is down to what you're doing I/O > against and how you're doing it. If you're doing it to a block device > of a real device then direct=1 usually won't touch the buffer cache. > If you're doing it to a file in a filesystem you're at the whim of the > filesystem (some do, some don't , some do unless you're using certain > options, some do so long as you get all the rules right but if you > don't then they quietly just use the buffer cache etc). I do notice > you're only doing reads and after laying out a file fio tries its best > to drop the cache for that file - > https://github.com/axboe/fio/blob/f09a7773f5821d5b89428419dcef1987ced39b67/filesetup.c#L509 > . On reflection, this should mean you're unlikely to be hitting the > kernel cache (maybe check how many I/Os the kernel sent to disk versus > those that fio was asked to do). > > > 2. "Maybe do I/O on a much larger file to see if the variation > > between runs goes down" - Will the file size be in some ratio of my > > system configuration?. For example if I am having a RAM of 32 GB then > > should I use a file of size of 64 GB or there are some other > > recommended best practices? > > This advice is to reduce the effectiveness of caching (if caching > really is taking place it might not be - see above). If most of your > I/O isn't going to cache then most of your I/O will reflect non-cache > speeds even if you are asking for buffered I/O. Doing too little I/O > is prone to be disturbed by other things that may be happening on the > system so I'd expect longer results to be more reliable. > > -- > Sitsofe | http://sucs.org/~sits/
