| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sat, 15 Mar 2008 21:03:08 +0000 From: Alan Cox <alan@...rguk.ukuu.org.uk> To: Daniel Phillips <phillips@...nq.net> Cc: Willy Tarreau <w@....eu>, David Newall <davidn@...idnewall.com>, linux-kernel@...r.kernel.org Subject: Re: [ANNOUNCE] Ramback: faster than a speeding bullet > > RAID controllers do not have half a terabyte of RAM. > > And? Either you have battery backed ram with critical data in it or > you do not. Exactly how much makes little difference to the question. It makes a lot of difference, and in addition raid controllers (good ones) respect barrier ordering in their RAM cache so they'll take tags or similar interfaces and honour them. > That is why I keep recommending that a ramback setup be replicated or > mirrored, which people in this thread keep glossing over. When > replicated or mirrored, you still get the microsecond-level transaction > times, and you get the safety too. Either you keep a mirror in sync and get normal data rates or you keep the mirror out of sync and then you need to sort your writeback process out to preserve ordering. If you want ramback to be taken seriously then that is the interesting problem to solve and clearly has multiple solutions if you would start to take an objective look at your work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists