Re: open(O_DIRECT) on a tmpfs?

[Bill Davidsen <davidsen@tmr.com>]

Peter Staubach wrote:
> Hugh Dickins wrote:
>> On Thu, 4 Jan 2007, Bill Davidsen wrote:
>>  
>>> In many cases the use of O_DIRECT is purely to avoid impact on cache 
>>> used by
>>> other applications. An application which writes a large quantity of 
>>> data will
>>> have less impact on other applications by using O_DIRECT, assuming 
>>> that the
>>> data will not be read from cache due to application pattern or the 
>>> data being
>>> much larger than physical memory.
>>>     
>>
>> I see that as a good argument _not_ to allow O_DIRECT on tmpfs,
>> which inevitably impacts cache, even if O_DIRECT were requested.
>>
>> But I'd also expect any app requesting O_DIRECT in that way, as a caring
>> citizen, to fall back to going without O_DIRECT when it's not supported.
>
> I suppose that one could also argue that the backing store for tmpfs
> is the memory itself and thus, O_DIRECT could or should be supported. 

I suspect that many applications don't try to distinguish an open error 
beyond pass/fail. If the application actually tried to correct errors, 
like creating missing directories, it might, but if the error is going 
to be reported to the user and treated as fatal there's probably no 
logic to tell "can't do it" from "could if you asked the right way."

I always thought the difference between Linux and Windows was the "big 
brother" attitude. If someone wants to use O_DIRECT and tmpfs, and the 
system can allow it, why have code to block it because someone thinks 
they know better how the users should do things.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979