On 12/01/2013 11:45 AM, Axel Dörfler wrote:
On 11/30/2013 05:03 PM, ingo_weinhold@xxxxxx wrote:065e6eb: ramdisk: Support file backingDoesn't your work on ramdisk indicate that we could do better at caching things? I mean, the only advantage it should have is that it never needs to actually write something back to slow storage.
I was actually considering adding an option to automatically sync with the image file. And I doubt that it would slow anything down noticeably. I think one -- maybe the main -- point is that journaling forces synchronization, which doesn't have much of a negative impact with a RAM disk.
I only have a vague idea of how BFS works. AFAIK it uses a long-running transaction into which it merges subtransactions for supposed-to-be-atomic FS operations, until it decides that the main transaction has to be committed. At which point all further FS operations block until that is done.
I don't know, whether that strategy is the problem or the BFS data structures, or whether it is some cache implementation deficiency. Something obviously is far from optimal. E.g. if I remove a large, already cached directory tree on Linux it may take a second, with some disk activity afterward. On Haiku (even with indices disabled) the same thing takes minutes, with heavy disk activity.
I suspect a proper analysis tool -- something similar to the DebugAnalyzer, just with FS, cache, and I/O focus -- will be needed to understand and properly address the issues.
CU, Ingo
