David Masover wrote:
Hans Reiser wrote:
| Chris Dukes wrote:
|
|>
|>
|> All filesystems will fail or suffer degraded performance under
|> certain conditions, you need to determine what conditions are acceptable
|> for your data.
|>
|>
|>
| and each generation of software reduces the extent of such conditions.
| Reiser4 fixes this problem cleanly.
I think Reiser4's degraded performance condition is when it gets lots of RAM. First, a disclaimer -- I don't have the latest reiser4 patch. But in all versions of the FS, I've found that if I'm ever trying to do anything when reiser finally decides to flush to disk, basically my whole system is locked up. I haven't tested, but I think this would actually be worse with more RAM, because it would be longer until the flush was forced, so each flush would take longer.
What is needed is some sort of estimator or estimate. An estimator would be something that would flush when, based on recent fs load, it was reasonable to expect that RAM would fill up just as the flush was completing. An estimate would be to flush if a certain percentage of RAM was full, and to go to synchronous mode if memory usage didn't go back below that percentage.
We need to throttle rather than flush, so as to ensure that for every page added to an atom, at least X pages must reach disk, until close to the end of the atom when we just flush it out.
Another missing and needed feature....
Hans
