add 2025-01-02_direct-io.md #45
Conversation
|
|
||
|  | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Using posix_fadvise with POSIX_FADV_DONTNEED could be an option if it doesn't make sense to totally avoid the cache (there's also Linux specific memory management options like MADV_COLD, which could help for some of the container concerns to optimise which memory is reclaimed, although it wouldn't likely have as much user visible impact on the page cache).
I suspect those don't make sense for the TSDB but could be worth mentioning here, there might be other places in the ecosystem where those make more sense than O_DIRECT.
There was a problem hiding this comment.
Thnaks, I'll mention that.
There was a problem hiding this comment.
Also, work on RWF_UNCACHED has resumed https://lore.kernel.org/linux-fsdevel/[email protected]/T/#cluster-upstream-ci
Thinking about going with an use-uncached-io feature flag, give direct I/O a chance, then reconsider once RWF_UNCACHED is usable.
|
|
||
| ## Why | ||
|
|
||
| Probably due to a lack of [understanding of good taste](https://yarchive.net/comp/linux/o_direct.html). |
There was a problem hiding this comment.
What's the purpose of this mention? (:
There was a problem hiding this comment.
just quoting @torvalds
Sadly, database people don't seem to have any understanding of good taste,
and various OS people end up usually just saying "Yes, Mr Oracle, I'll
open up any orifice I have for your pleasure".
Linus
(it's a joke :))
Signed-off-by: machine424 <[email protected]>
Signed-off-by: machine424 <[email protected]>
kick off PR prometheus/prometheus#15365