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/
