> We don't need fadvise IMHO. That is what open(2) is for. The streaming 
> request you are asking for is just a normal open(2). It will do read 
> ahead which is perfect for streaming (of data size << RAM size in its 
> current form).
>
> When you want large data streaming, i.e. you start getting worried 
> about memory pressure, then you want open(2) + O_DIRECT. No caching 
> done. Perfect for large data streams and we have that already. I agree 
> that you may want some form of asynchronous read ahead with passed 
> pages being dropped from the cache but that could be just a open(2) + 
> O_SEQUENTIAL (doesn't exist yet).
>
> All of what you are asking for exists in Windows and all the semantics 
> are implemented through a very powerful open(2) equivalent. I don't 
> see why we shouldn't do the same. It makes more sense to me than 
> inventing yet another system call...
I disagree, and here's the main reasons:
* fadvise(2) usefulness extends past open(2).  It may be useful to call 
it at various points during runtime.
* I think putting hints in open(2) is the wrong direction to go.  Hints 
have a potential to be very flexible.  open(2) O_xxx bits are not to be 
squandered lightly, while I see a lot more value in being a little more 
loose and free with the bit assignment for an "fadvise mask" (just a 
list of hint bits).  IMO it should be easier to introduce and retire 
hints, far easier than O_xxx flags.
    Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/