WARNING: Off-topic ZFS blathering just because I like spreading the gospel. ;-)
I don't think I've heard of writezillas.
Not sure the origin, but a Readzilla was just a (rebranding I guess?) STEC Mach8 100GB SSD used as a read-cache. In fact, the Readzilla name is rarely used anymore. The technical name if L2ARC, or Level-2-Adapative-Read-Cache (Level-1 being the system memory ZFS consumes for caching). In operation, this will almost always be used close to capacity as long as you have that much data in the disks behind it.
A Logzilla was a STEC Zeus IOPS (18GB). It operated as something similar to a RDBMS transaction log, aka the "ZFS Intent Log", or ZIL. This is a Write-Back-Cache. Even if you're only running HDDs the ZIL is still there to ensure consistency. If you have SSDs to spare, you have the option of moving the ZIL to those to increase write performance (up to the point you fill up the SSD anyways, which doesn't really happen in practice, though it's possible).
If you lose an L2ARC device, no worries, it's pure cache. Even if it's your only L2ARC device, the worst that's going to happen is things slow down because there's no SSD caching your data anymore. With that in mind, I usually deploy two SSDs for an L2ARC, in a striped configuration to increase IOPs. If I lose one, I still have another, just half the IOPs. If I lose both, well, back to just the performance of my disks, but all my data is safe.
If you lose your ZIL, you've lost your zpool (the whole logical storage array). This means you must MUST MUST always have at least two drives for your ZIL, and they should be mirrored so if there's a failure your data is still safe. Moving the ZIL off to SSD increases performance, and is absolutely something you should do, but similar to the Fusion Drive (though for entirely different reasons), the SSD isn't simply a performance booster, you're actually moving a critical part of your storage system to it. It needs to be protected.
More Trivias: Since the ZIL is part of the storage, this is why the Sun Storage clusters had the ZIL inside the JBODs and not on the 1U server heads. If you failed over from one head to another, you needed to make sure the ZIL went with the backing disks. The heads did contain the SSDs used for L2ARC OTOH since cache is cache, after failing over the new "array master" would just populate it's SSDs as data was read.
That seems like you're really living on the edge. :-)
My typical setup is:
2.5" 15K-RPM HDDs making up the storage array. Generally in 4 or 5 drive, single parity sets with a spare for every set up to 3 spares (more just seems silly). I build out the array with 2 to 4 sets generally. The more sets, the more capacity and performance while keeping your parity stripes a reasonable size and ensuring a single drive failure doesn't drastically degrade the performance of the whole array.
So with 300GB drives, that gives me (300GB * (5 - 1 (for parity))) * 2 == ~2.4TB usable. Then throw on a couple Crucial M4s or Samsung 830s (had very bad luck with most Sandforce equipment) as striped L2ARC, and another pair as mirrored ZIL.
Then use a caching RAID controller with a BBU in JBOD mode.
The reason you want 15K-RPM drives is that things like replication and volume creation/deletion bypass the ZIL and caches, so while most of the time you'll be able to push ~30K 8K blocks around in either direction sustained with ease, for the low level administrative things you'll be limited by your disk speed. Which in the 10 drive (including spares) 2.4TB example above means you'll have about 1200 IOPs worth of performance you can tap into. If you'd instead used a three-drive single-parity set with 2TB SATA drives, you'd be storing a lot more data on each drive, meaning failures would take much longer to recover from, not to mention the drives themselves would be about half the speed. On top of that, for the lower level operations you'd be limited to about 1/10th the IOPs. Which is not fun at all. Especially if you've made the mistake of attempting to use deduplication. :-(
This is last-generation stuff though. These HDDs offer less storage, and much less performance for about twice the price of a good 512GB SSD today. Any new arrays I build will forgo the L2ARC and ZIL, and go full SSD.
This way you can cut out the 4 SSDs used in the example, and instead of 10 drives, have 10 SSDs. Instead of around ~30K 8K IOPs, you'll have access to 120K. Instead of about 15K for writes, you'll have about the same 120K. And all your lower level administrative tasks will run at the same speed as everything else.
So you'll end up with about 4X the performance at less than half the price, and with ~40% more storage as well. So even if you need the array to have a 4 year life-span, you could replace all the SSDs every couple of years, and continue to expand the performance envelope with whatever the current generation offers, and still end up paying less. Not to mention drive bays aren't cheap. So the all-SSD option means a Dell R820 with 16-bays is now an option whereas before you'd need the 10 drive bays, 4 bays for SSD, and your mirrored boot devices... you'd be looking at buying a pretty pricey MD1220 in addition to the server and now you've given up another 2U as well.
For high-performance IT HDDs are all but dead. We've passed a price/GB/performance milestone where for 98% of use cases, HDDs should only be considered for archival storage, not operational storage. IMO.
I don't think I've heard of writezillas.
Not sure the origin, but a Readzilla was just a (rebranding I guess?) STEC Mach8 100GB SSD used as a read-cache. In fact, the Readzilla name is rarely used anymore. The technical name if L2ARC, or Level-2-Adapative-Read-Cache (Level-1 being the system memory ZFS consumes for caching). In operation, this will almost always be used close to capacity as long as you have that much data in the disks behind it.
A Logzilla was a STEC Zeus IOPS (18GB). It operated as something similar to a RDBMS transaction log, aka the "ZFS Intent Log", or ZIL. This is a Write-Back-Cache. Even if you're only running HDDs the ZIL is still there to ensure consistency. If you have SSDs to spare, you have the option of moving the ZIL to those to increase write performance (up to the point you fill up the SSD anyways, which doesn't really happen in practice, though it's possible).
If you lose an L2ARC device, no worries, it's pure cache. Even if it's your only L2ARC device, the worst that's going to happen is things slow down because there's no SSD caching your data anymore. With that in mind, I usually deploy two SSDs for an L2ARC, in a striped configuration to increase IOPs. If I lose one, I still have another, just half the IOPs. If I lose both, well, back to just the performance of my disks, but all my data is safe.
If you lose your ZIL, you've lost your zpool (the whole logical storage array). This means you must MUST MUST always have at least two drives for your ZIL, and they should be mirrored so if there's a failure your data is still safe. Moving the ZIL off to SSD increases performance, and is absolutely something you should do, but similar to the Fusion Drive (though for entirely different reasons), the SSD isn't simply a performance booster, you're actually moving a critical part of your storage system to it. It needs to be protected.
More Trivias: Since the ZIL is part of the storage, this is why the Sun Storage clusters had the ZIL inside the JBODs and not on the 1U server heads. If you failed over from one head to another, you needed to make sure the ZIL went with the backing disks. The heads did contain the SSDs used for L2ARC OTOH since cache is cache, after failing over the new "array master" would just populate it's SSDs as data was read.