Hi Miguel and all, Just two small notes and I'll stop talking about SSD before somebody thinks I want to convince anyone instead of just making a suggestion:
1-No system will be 100% corruption free. Yes even fancy caches with battery. We are talking about probabilities here. And the case of a SSD losing power while erasing a page to write a block is a possibility but with low probability. In fact, that operation on the SSD firmware can be logged or be done on a COW mode. (I really hope next generation filesystems ALL implement checksumming like ZFS, btrfs etc... that's the way to go) 2- I know that's not the case here, but I always cringe when I see the faith some people put in RAID. It's not a magic bullet. Mechanical drives have a higher probability of failing than the rest of the system so it makes sense, specially to avoid down time. Data safety is guaranteed by backups. Only by backups. On that note, I don't see the point of mirroring or striping SSD. Are they really that much unreliable than the computer itself? The power supply? The operator of the computer? :-) My only doubt for a database server would be if the workload implied a lot of *sustained* writes. Thats a point where SSDs just don't cut it. Cheers, HG On Dec 14, 2009, at 8:08 PM, Miguel Arroz wrote: > Hi! > > I'm starting to look like the cranky guy over here, but I would not trust > SSD either. :) > > There are a lot of problems, some potencial, some real, like problems in > production, fragile hardware, finite number of writes, bugs in the firmware, > etc. But there's one bigger problem that is largely unknown by most people. > > Disk drives are block devices, with very small block sizes (from 512 bytes > to 4K). Flash drives are raw devices with much larger memory cells (128k or > more). What does this mean? It means new drivers SHOULD have been written for > all OSes to support flash drives as raw devices, and deal with their way of > doing things. But that would only happen if our industry was at least a bit > decent, and if everyone was not fighting for quick profit selling crap. So, > what has really been done was building firmwares that expose the raw device > as a block device for the OS, and do all the necessary conversions on the fly. > > It happens that most firmwares, as Anjo would say :), are shit. How shitty, > depends on the brand and model, Intel seem to have the best ones, but many > others plain suck. And why? Because they have a really big problem, they WILL > corrupt data if the power is lost during a write. This is the part you say, > hey, that also happens on a hard drive, that's why file systems have > journaling, right? Wrong. Because of another fact: when you change the > contents of a memory cell (even if you're changing one bit), due to how the > flash memory works, you have to read the whole cell to a buffer, change it's > content, erase the cell completely and write the full data back to the cell. > So, imagine this: > > 1) OS writes on the journal that sector X will change with the data Y. > > 2) Flash writes the log (let's assume this happens without problems for now). > > 3) OS writes Y for sector X on the flash. > > 4) Flash firmware will read the entire memory cell where sector X is stored > (among many others), and apply the content change to the buffer. > > 5) Flash firmware will erase the original cell. > > 6) Flash firmware will write the cell again with the new data. > > Now, imagine power is lost during step 5 or 6. You're dead. Why? Because > your journal only has information about sector X - not all the sectors that > are (or should I say... were) in the affected memory cell. Scared? Yes, you > should be. > > As always in IT, flash disks started in the very wrong way. And it will take > time to bring them to the right track. During that period, use good old hard > drives. > > (Even with all this problems aside, flash drives are electronics and > electronics may fail. I would NOT stop using RAID just because flash has not > mechanical issues.) > > Yours > > Miguel Arroz > > On 2009/12/14, at 18:57, Henrique Gomes wrote: > >> If you really need 1Tb now and only spend <$1000 then don't read the rest :-) >> >> If you can live with 500GB and can spend a little more, think about a 500GB >> SSD drive and forget the RAID part, one SSD drive is faster than two >> mechanical drives (no seek time) and I see no point in mirroring them as >> the main causes for it are gone with flash; no bad sectors, no head crash >> etc... And you are going to backup regularly even if mirroring right? >> >> A search for '500gb ssd' gives OCZ drives for ~ $1500. You can then either >> get an e-sata or firewire enclosure. Or move the internal drive to an >> external enclosure and put the SSD inside if that's were the majority of >> disk traffic is going to be. >> >> The reason I bring this up is that I just replaced the drive on my macbook >> pro with an Intel SSD and altough it's a smaller one (80GB) I'm still >> amazed with the performance. My dashboard took >30secs to fully initliaze, >> now it's more like 2 seconds. Eclipse, openoffice and other really slow >> starters appear in 3 or 4 seconds. Did I say it's fast? >> >> Henrique >> >> On Dec 14, 2009, at 6:15 PM, Kieran Kelleher wrote: >> >>> Thanks for the warning! Thanks to everyone for responses so far..... >>> >>> OK, so regular 4-drive RAID 1+0 is what it will be, either the OWC or one >>> of the ones recommended below. >>> >>> Next up ....... eSATA PCI cards for Dual G5 XServe - anyone have any good >>> recommendations? Here is one I found: >>> http://www.datoptic.com/cgi-bin/web.cgi?product=eSATA_pcix&detail=yes >>> >>> -Regards, Kieran >>> >>> On Dec 14, 2009, at 12:47 PM, ACN wrote: >>> >>>> Run, don't walk, away from the Drobo. While the later Firewire based >>>> models may have improved, our interaction with the first gen models went >>>> like this... Plug unit in. Trust your data to it. Have no data. Let me >>>> put it another way. Drobo came to us for a little dog and pony show. >>>> They left us our NFR and before the rep made it to the elevator, we broke >>>> it so bad he took it back. This is a true story. On of my hardware guys >>>> killed the unit in less than 5 minutes while doing the supposedly >>>> supported drive swap. >>>> >>>> The OWC device looks nice if you need rack mount storage (I've had no >>>> experience with it). If you are set on a 4 drive unit, we recommend for >>>> our customers either: ArticRoc >>>> (http://www.rocstor.com/Products/arcticroc-4t.html), the RTX-400 >>>> (http://www.wiebetech.com/products/RTX400QR.php), or the HDElement >>>> (http://www.caldigit.com/HDElement/). The CalDigit stuff we usually use >>>> for video customers so you are likely not looking for that type of >>>> transactional storage. The others have proven to be flexible and reliable. >>>> >>>> Stay away from the Lacie stuff. Again, many bad experiences (although >>>> they now have a tempting rack mount unit for FC but the price is likely >>>> too high for your needs). The MyBook drives are also not high on my >>>> recommend list. >>>> >>>> Hope this helps >>>> >>>> R- >>>> >>>> >>>> On Dec 14, 2009, at 9:04 AM, Kieran Kelleher wrote: >>>> >>>>> Hi All, >>>>> >>>>> Looking for suggestions for an economical (< $1000) "poor man's" RAID 1+0 >>>>> 4-drive storage solution for a dual 2.0 G5 Xserve that must be used as a >>>>> dedicated database server. It is a cluster node model with just one >>>>> hard-drive bay. >>>>> >>>>> It has Firewire 800 ports and 2 PCI-X slots. One PCI slot has a video >>>>> card, one is empty. >>>>> >>>>> I was thinking possibly of a esata PCIX card with a OWC 4-drive hardware >>>>> RAID rack unit: >>>>> http://www.datoptic.com/cgi-bin/web.cgi?product=eSATA_pcix&detail=yes - >>>>> $99 >>>>> http://eshop.macsales.com/shop/hard-drives/RAID/Rack_Mount/FireWire_eSATA_USB2_RAID >>>>> - $850 (includes 4 x 500GB enterprise hard drives) >>>>> >>>>> There will be 2 slaves continuously replicating for additional data >>>>> protection. >>>>> >>>>> Any thoughts or other suggestions? >>>>> >>>>> Regards, Kieran >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-deploy mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> http://lists.apple.com/mailman/options/webobjects-deploy/acn%40carbontechnologies.com >>>>> >>>>> This email sent to [email protected] >>>> >>>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-deploy mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-deploy/lists%40farol.pt >>> >>> This email sent to [email protected] >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-deploy mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-deploy/arroz%40guiamac.com >> >> This email sent to [email protected] > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-deploy mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com This email sent to [email protected]
