hubcio commented on issue #4048: URL: https://github.com/apache/iggy/issues/4048#issuecomment-5525999317
technically yes, but those presumed gains are not measured. feel free to do that by yourself - as of now we plan to extend iggy with tiered storage, harden VSR and work on core features which actually add new functionalities. this one does not do that.... it's a mount and a config line, not a new capability. ssd wear and disk writes are already gone with tmpfs, and with `enforce_fsync = false` (the default) the ack path never waits on the disk anyway. on the memory side i also don't see where the win comes from. the server keeps no separate in-memory message cache, reads go through the page cache, and tmpfs pages *are* page cache, so there's no double copy to remove. indexes are already held in memory. what's left is a syscall and a memcpy per read/write. maybe measurable, nobody measured it. the cost is permanent though - a second storage backend puts a branch in every segment/index/metadata/state path and has to stay correct forever, VSR included. that's a lot of surface for something you get today with `mount -t tmpfs`. if you benchmark tmpfs vs a prototype in-memory backend and there's a real gap, post the numbers here and it's a different conversation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
