On Saturday 15 March 2008 14:54, Willy Tarreau wrote:It already has ordered write when it is in flush mode. OK, I hear you. There will be an ordered write mode that uses barriers to decide the ordering. It will greatly reduce the speed at which ramback can flush dirty data because of the need to wait synchronously on every barrier, of which there are many. And thus will widen out the window during which UPS power must remain available if power goes out, in order to get all acknowledged transactions on to stable media. The advantage is, the stable media always has a point-in-time version of the filesystem. Don't expect this mode in the immediate future though, there are bugs to fix in the current driver, which already implements the required performance and stability requirements for a broad range of users. That would have been a miscommunication then. I see arguments coming in that suggest embedded solutions, EMC for example, are inherently more reliable than a Linux based solution. Well guess what? Some of those embedded solutions already use Linux. Also, peecees are much more reliable than people give them credit for, especially if you harden up the obvious points of failure such as fans and spinning disks. Once you have your system all hardened up, then you _still_ better replicate your important data. Perhaps I should not admit this, but I simply fail to do that on the machine from which I am posting right now, which also runs my web server and mail system. That is because I would have to reboot it to install ddsnap so I can replicate properly, and because the thing is so darn reliable that I just have not gotten around to it. I do copy off the important files from time to time though, and do various other things to ameliorate the risk. If it was enterprise data I would obviously do a lot more. My immediate goal is to replace disk with RAM. Exactly what I mean: close but not there. Those gigantic RAM boxes are shipping now, and the same company has got a 5 TB flash box coming down the pipe, and sooner than Q3. But the RAM box will always outperform the flash box. You just keep throwing writes at it until all available flash is in erase mode, and the thing slows down. If that is not a problem for you, then great, you can also save a lot of money by going with flash. But if nothing less than the ultimate in performance will do, RAM is the only way to go. Daniel --
| Alan Cox | [PATCH 00/76] Queued TTY Patches |
| Linus Torvalds | Linux 2.6.27 |
| Eric W. Biederman | [PATCH] nfsd/nfs4state: Remove unnecessary daemonize call. |
| Artem Bityutskiy | [PATCH 10/44 take 2] [UBI] debug unit implementation |
git: | |
| Daniel Barkalow | Re: I don't want the .git directory next to my code. |
| Johannes Schindelin | Re: [PATCH] RFC: git lazy clone proof-of-concept |
| Johannes Schindelin | Re: [ANNOUNCE] GIT 1.5.4 |
| Johannes Schindelin | Re: git-diff on touched files: bug or feature? |
| Richard Stallman | Real men don't attack straw men |
| Juan Miscaro | When will OpenBSD support UTF8? |
| Stefan Beke | mail dovecot: pipe() failed: Too many open files |
| L. V. Lammert | Re: About Xen: maybe a reiterative question but .. |
| Michael Buesch | Re: Mark IPW2100 as BROKEN: Fatal interrupt. Scheduling firmware restart. |
| Johannes Berg | Re: mac80211 truesize bugs |
| Vitaliy Gusev | [TCP]: TCP_DEFER_ACCEPT causes leak sockets |
| Alexey Dobriyan | [PATCH 10/33] netns ct: per-netns /proc/net/nf_conntrack_expect |
