Hi Pavel, On Saturday 15 March 2008 13:18, Pavel Machek wrote:Ramback is supposed to prevent that by allowing only a limited amount of application IO during flush mode. Currently this is accomplished by making each application write wait synchronously on the one before it, until flushing completes. This allows only a small amount of application traffic, something like 5% bandwidth. This solution is admittedly crude, and over time it will be improved to look more like a realtime scheduler, because this is in fact a realtime scheduling problem. Once flushing completes, application writes are still serialized and thus slow, which is a stronger condition than necessary to maintain transactional integrity for the filesystem. Eventually this will be optimized. For now, the maximum flush is only a few hundred MB on my workstation, which leaves a huge safety margin even with my $100 UPS. And the risk, however small, of having to run a lossy e2fsck because the battery got old and the power did run out, is mitigated by the fact that ramback runs on my kernel hacking partition, and everything unique there just gets uploaded to the internet regularly anyway. This serves as my replication algorithm. Note: I strongly recommend that any critical data entrusted to ramback be replicated to mitigate the risk of system failure, however small. No, you are missing some essential pieces. Ramback has two operating modes: 1) writeback (when ups-backed line power is available) 2) writethrough (when running on ups power) Plus, it has the daemon driven flushing for ups mode, and daemon driven one-pass populating for startup mode. That is all ramback is, but you do not quite get there with your solution above. Also, ramback works with generic block devices, opening up a wide range of applications that your proposal does not. We sure do. Readahead sucks enormously in Linux. I hope that my work inspires other people like you to go in and work on some of the VM/VFS/BIO brokenness that helps make ramback such a big win. In the meantime, it is useful to be clear on just what we have here, and why some people care about it a lot. Daniel --
| Andi Kleen | [PATCH x86] [6/16] Add a new arch_early_alloc() interface for x86-64 |
| Jay L. T. Cornwall | 2.6.22-rc5: pdflush oops under heavy disk load |
| Adrian Bunk | If you want me to quit I will quit |
| H. Willstrand | Re: AMD Quad Core clock problem? |
git: | |
| Pietro Mascagni | GIT vs Other: Need argument |
| Wink Saville | Resolving conflicts |
| Wink Saville | Using git with Eclipse |
| Toby White | Using Filemerge.app as a git-diff viewer |
| GVG GVG | ssh_exchange_identification: Connection closed by remote host |
| Beavis | mutiple pptp pass-through PF |
| Andrei Pirvan | apache 1.3.29 + PHP 5.2.6 on OpenBSD 4.4 |
| STeve Andre' | Re: Perpetually Current |
| Herbert Xu | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Denys | r8169 crash |
| David Miller | Re: [crash] BUG: unable to handle kernel NULL pointer dereference at 0000000000000... |
| Jianjun Kong | [PATCH 2/6] nets: clean up net/ipv4/ipip.c raw.c tcp.c tcp_minisocks.c tcp_yeah.c ... |
