also you probably don't want spares. If I had drives plugged in using power and spinning all the time i think I would want to be using the storage of them.
You may want spares in the event you've already maxxed out the available redundancy option. For example, on a 12-drive filer, I've used RAIDZ3 on 11 drives to get an optimal config and placed the last drive as spare. This means I can initiate a replacement operation without touching the hardware and gives me something like RAIDZ3-and-a-half-kinda. The spare drive has run for as long as the pool itself has and is subject to the same SMART testing to identify problems, so it is basically ready to go the instant it is needed.
My intent is not to use (too much or not at all) compression due the fact that's real Home-Server and not needed for enterprise tasks even later hence I will not stress to much RAM/HDD-capacity relation.
That said, of course would test also RaidZ2 but only by problems with RaidZ3, though already tested ICH8 and mdadm Raid 1+0 and can compare.
I read also some discussion about RaidZ3/2 but also understand that Z3 running better/stabler with ZIL and L2ARC and that will be implemented. My opinion is that by ICH8 and mdadm the hardware have also to let run other (multi-)tasks respectively in Win or Linux and that cause freezing and data loss for all in Win and very long rebuild in Linux.
The hardware (MoO) should have Intel C Chipset supporting 64 GB RAM, ECC-RAM and a Xeon with integrated graphic-Card. Build one and never touch besides ADD cards for Network and additional SATA-Data connections.
Assumed that Z3 will have ZIL and L2ARC with correlated 1 less drive for storage, which else assumption/experience have you with Z3?
You seem to have a lot of information, some of it a bit odd.
1) ZFS is relatively big and eats resources. 8GB is a small or even tiny system.
2) Almost everyone should have compression enabled, unless you have a totally pathetic CPU. Compression primarily costs you when writing to disk; reading (decompression) is nearly free with any vaguely modern CPU. Your available disk space will increase (by an unknown amount) with no capex involved. Free beer!
3) You do not want L2ARC on an 8GB system. Once you get out to 64GB, maybe - but not likely to be useful on a home system. When your pool is very busy, L2ARC can act as a sort of turbo-boost to get more IOPS out of it. If your pool isn't busy, you're probably fine just pulling the data from the pool.
4) What you're calling ZIL is probably a SLOG, a separate log device. You probably don't need that unless you can clearly explain why you do.
5) RAIDZ3 works fine and the main issue is that you get reduced write performance.
6) Please bear in mind that a lot of the RAM sizing is vague. I deliberately rewrote bits of the handbook to be vague. Does it mean 1GB per 1TB of attached disk space? 1GB per 1TB of usable disk space? 1GB per 1TB of used disk space? There's no actual magic formula. We just know that that more disk needs more RAM and this seems to size well for general purpose uses. A heavily used fileserver might need substantially more.
