> On 2010-Sep-24 00:58:47 +0800, "R.G. Keen" > <k...@geofex.com> wrote: > > But for me, the likelihood of > >making a setup or operating mistake in a virtual machine > >setup server is far outweighs the hardware cost to put > >another physical machine on the ground. > > The downsides are generally that it'll be slower and less power- > efficient that a current generation server My comment was about a physical machine versus virtual machine, and my likelihood of futzing up the setup, not new machine versus old machine. There are many upsides and downsides on the new versus old questions too.
>and the I/O interfaces will > be also be last generation (so you are more likely to be stuck with > parallel SCSI and PCI or PCIx rather than SAS/SATA and PCIe). And > when something fails (fan, PSU, ...), it's more likely to be customised > in some way that makes it more difficult/expensive to repair/replace. Presuming what you did was buy a last generation server after you decided to go for a physical machine. That's not what I did, as I mentioned later in the posting. Server hardware in general is more expensive than desktop, and even last generation server hardware will cost more to repair than desktop. To a hardware manufacturer, "server" is synonymous with "these guys can be convinced to pay more if we make something a little different". And there is a cottage industry of people who sell repair parts for older servers at exorbitant prices because there is some non-techie businessman who will pay. > Not quite. When Intel moved the memory controllers from the > northbridge into the CPU, they made a conscious decision to separate > server and desktop CPUs and chipsets. The desktop CPUs do not support > ECC whereas the server ones do So, from the lower-cost new hardware view, newer Intel chipsets emphatically do not support ECC. The (expensive) server-class hardware/chipsets, etc., do. A lower-end home class server is unlikely to be built from these much more expensive - by plan/design - parts. > That said, the low-end Xeons aren't outrageously expensive They aren't. I considered using Xeons in my servers. It was about another $200 in the end. I bought disks with the $200. >and you > generally wind up with support for registered RAM and registered ECC > RAM is often easier to find than unregistered ECC RAM. I had no difficulty at all finding unregistered ECC RAM. Newegg has steady stock of DDR2 and DDR3 unregistered and registered ECC. For instance: 2GB 240-Pin DDR3 ECC Registered KVR1333D3D8R9S/2GHT is $59.99. 2GB 240-Pin DDR3 1333 ECC Unbuffered Server Memory Model KVR1333D3E9S/2G is $43.99 plus $2.00 shipping. 2GB 240-pin DDR3 NON-ECC is available for $35 per stick and up. The Kingston brand I used in the ECC examples is $40. These are representative, and there are multiple choices, in stock, for all three categories. "Intel certified" costs more if you get registered. > > AMDs do, in general. > AMD chose to leave ECC support in almost all their higher-end memory > controllers, rather than use it as a market differentiator. AFAIK, > all non-mobile Athlon, Phenom and Opteron CPUs support ECC, whereas > the lower-end Sempron, Neo, Turion and Geode CPUs don't. I guess I should have looked at the lower end CPUs - and chipsets before I took my "in general" count. I didn't, and every chipset I saw had ECC support. My lowest end CPU was the Athlon II X2 240e, and every chipset for that and above that I found supports ECC. > In the case of AMD motherboards, it's really just laziness on the > manufacturer's part to not bother routing the additional tracks. And doing the support in bios. I did research these issues a fair amount. For the same chipset, ASUS MBs seem to have bios settings for ECC and Gigabyte, for instance, do not. I determined this by downloading the user manuals for the mobos and reading them. I didn't find a brand other that ASUS that had a clear support for ECC in the bios. But my search was not exhaustive. > On older Intel motherboards, it was a chipset issue rather than a > CPU issue (and even if the chipset supported ECC, the motherboard > manufacturer might have decided to not bother running > the ECC tracks). I think that's generically true. > Asus appears to have made a conscious decision to support ECC on > all AMD motherboards whereas other vendors support it sporadically > and determining whether a particular motherboard supports ECC can > be quite difficult since it's never one of the options in their > motherboard selection tools. Yep. I resorted to selecting mobos that I'd otherwise want, then downloaded the user manuals and read the bios configurations pages. If it didn't specifically say how to configure ECC, they it MIGHT be supported somehow, but also might not. Gigabyte boards for instance were reputed to support ECC in an undocumented way, but I figured if they didn't want to say how to configure it, they sure wouldn't have worried about testing whether it worked. > And when picking the RAM, make sure it's compatible with your > motherboard - motherboards are virtually never compatible with > both unbuffered and buffered RAM. Yep. Once I selected mobos on features other than ECC, I investigated ECC, and where that was supported, researched the issue of the specific ECC memory brand on the mobo site and memory vendor site. There was a premium price attached to both registered memory sticks and the mobos that needed them. I guess what amounts to the mid range chipsets for AMD all used unbuffered/unregistered ECC memory. The higher end CPUS were out of my selection criteria because of the heat and power load, so I didn't find the registered ECC mobos in AMD chipsets. > >Think about what happens if you find a silent bit corruption in > >a file system that includes encrypted files. > Or compressed files. That'll do it too. I personally don't compress files I think it's critical that I keep. That side steps the issue of things like images which normally contain compression, but I had some bad experiences which taught me the similarity between corrupted compressed files and encrypted files for which you don't have the password. I'm probably too conservative that way. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
