On 10/26/2017 01:05 PM, Sitsofe Wheeler wrote:
> On 26 October 2017 at 19:06, Jens Axboe <axboe@xxxxxxxxx> wrote:
>> On 10/25/2017 10:32 PM, Jens Axboe wrote:
>>> On 10/24/2017 08:10 AM, Paolo Valente wrote:
>>>>
>>>>> Il giorno 24 ott 2017, alle ore 08:28, Sitsofe Wheeler <sitsofe@xxxxxxxxx> ha scritto:
>>>>>
>>>>> Hi,
>>>>>
>>>>> If memory serves it's actually slightly more complicated. If you are
>>>>> using loops=<number> then I *think* (you'll have to check) you will
>>>>> find that invalidation happens once per each loop start. However when
>>>>> you use time_based to do the repetition there is essentially only one
>>>>> "loop" (even though the job goes on forever) so loop actions only
>>>>> happen right at the start of the job with that option (that's why I
>>>>> put the scare quotes around "beginning" ;-).
>>>>>
>>>>
>>>> Thanks for this additional, useful piece of information. Actually,
>>>> this further, possibly different caching behavior makes me think that
>>>> some extra comment in the manpage might be helpful.
>>>
>>> Would probably make sense to change 'invalidate' to be a range of
>>> possible values:
>>>
>>> 0 As it is now, never invalidate
>>> 1 As it is now, invalidate initially
>>> once Same as '1', invalidate initially / once
>>> open New value, invalidate on every open
>>> close New value, invalidate on close
>>>
>>> as I can definitely see reasons why you would want to invalidate every
>>> time you open the file.
>>>
>>> To do that, the 'invalidate' option should be changed from a
>>> FIO_OPT_BOOL to a FIO_OPT_STR, and the above possible values should be
>>> added as posval[] for that option.
>>>
>>> Compliment that with the an enum of ranges for the ovals:
>>>
>>> enum {
>>> FIO_FILE_INVALIDATE_OFF = 0,
>>> FIO_FILE_INVALIDATE_ONCE,
>>> FIO_FILE_INVALIDATE_OPEN,
>>> FIO_FILE_INVALIDATE_CLOSE
>>> };
>>>
>>> Hope this makes sense, should be trivial to add as most of the work is
>>> already documented in this email :-). The remaining bits is just calling
>>> file_invalidate_cache() in the proper locations,
>>> td_io_{open,close}_file() would be prime candidates.
>>
>> On a plane, so decided to take a look at this. Looking at how it's
>> implemented, fio actually does do cache invalidation at open time,
>> if you look at td_io_open_file(). I traced it, and it's invoked just
>> fine by default, and if you use loops=X (with X > 1).
>
> I was going to say - when I did the "windowsaio invalidate" I noticed
> invalidation seemed linked to open.
>
>> For time_based, we don't open and close the file, so we don't trigger
>> that at all. We just loop/reset the offsets. Something like the below
>> should do the trick.
>
> Unfortunately I don't think it's easy to do effective invalidation
> with open file handles on Windows so I think windowaio will have to
> stay as is when using time_based. Is it OK that we don't change that
> ioengine for now?
It would be cleaner if we just closed/opened the files... But that's
easier said than done, since we'd have to quiesce IO and wait for
references to the file to go away.
And even then it won't necessarily work on Windows, since it only
works if that instance is the only opener of it.
Haven't we documented that invalidation on windows is best effort?
It already is, even from the initial run.
--
Jens Axboe
--
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
