On 16:11 Tue 11 Jul , Hans Reiser wrote: > Clay Barnes wrote: > >On 15:04 Tue 11 Jul , Hans Reiser wrote: > >>6) optimize fsync --- substantive task which requires using fixed area > >>for write twice logging, and using write twice logging for fsync'd > >>data. It might require creating mount options to choose whether to > >>optimize for serialized sequential fsyncs vs. lazy fsyncs. > >With the serialized sequential fsync, is that essentially what I was > >talking about earlier with slowly streaming dirty writes to disk when > >the HDD is idle? If that's the case, I don't see the advantage in having > >lazy fsyncs > if you are optimizing throughput rather than latency, then you let > things get to disk whenever they get there, and you let the app hang > while it waits. A mailer processing many requests in parallel might find > 30 seconds of latency to be just fine but a database might find 3 > seconds of latency to be too much. (I make up these examples, mailer > programmers please correct me.) I see your point, but here's where I'm still uncertain:
If you have a lazy write policy, what exactly is gained by intentionally delaying writes (beyond a certain size that is necessary to make things like dancing trees actually effecient)? If you trickle some data to disk, then when memory pressure causes (or an app calls) a big sync, then you have less to actually write. What I'm suggesting, now, is not a major write policy change, but rather a light process that is limited to extremely low resource use (I/O, CPU, etc.). It would take some of the edge off of major syncs, and for many (most?) non-server users, it could wholly eliminate memory pressure-induced heavy syncs. --Clay
