Date: Wed, 3 Jan 2001 19:24:39 +1030 From: Greg Lehey <grog@lemis.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Zero Sum <count@shalimar.net.au>, Jim King <jim@jimking.net>, Alfred Perlstein <bright@wintelcom.net>, Thomas Seck <tmseck@web.de>, freebsd-stable@FreeBSD.ORG Subject: Re: RAID costs (was: Vinum safe to use for raid 0?) Message-ID: <20010103192438.V4336@wantadilla.lemis.com> In-Reply-To: <200101030758.f037wQZ45135@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Jan 02, 2001 at 11:58:26PM -0800 References: <20010102230107.A559@basildon.homerun> <01010313305000.03936@shalimar.net.au> <00e301c0752e$7ba65e60$04e48486@marble> <01010315274900.04373@shalimar.net.au> <20010103172132.T4336@wantadilla.lemis.com> <200101030758.f037wQZ45135@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 2 January 2001 at 23:58:26 -0800, Matt Dillon wrote: > Like everything, topologies have their strengths and weaknesses. > RAID-5 is excellent for read-centric operations (which large data stores > tend to be, I will note) and, as Poul reminded me a few days ago... > stripe-sized block-write operations can be made optimal. Well, they can be optimized, which isn't quite the same thing. That's a wish list item for Vinum. > Of course, it has to be reliable to be useable, which is really > the crux of the current thread. Someone needs to buy Greg some > faster machines to play with :-), as the current vinum issues > appear to be related to timing. I'm not sure about that, though it's possible. The real issue with my test setup is that the disks I have are all ancient. I'm getting some more modern ones Real Soon Now, but of course the optimum way to solve this particular problem would be if somebody sent me exactly the machine that was having trouble. > There are other big differences between software and black-box > RAID solutions. For example, what happens when the machine > crashes right smack in the middle of a write? Hardware RAID > (e.g. RAID-5) solutions have NVRAM to hold the log. Software > RAID either has to be extremely careful in the sequencing of the > data, play serial number tricks (which is why you sometimes see > disks with weird physical sector sizes), or write a separate log > and delay the actual disk updates until the log write has been > confirmed. Indeed. Vinum cheats a little here, but even then it seem to be too finicky for many people. Theoretically, after a crash you need to synchronize the volumes. I'm thinking of a volume manager logging facility which will keep track of the last n operations. This would enable recovery code to confirm that they had been performed. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010103192438.V4336>