I'll keep on debunking this :-) This is NOT a requirement. The more RAM you have, the more ZFS will cache. If you're running a single user system or don't move a lot of data you can get around with way less and never notice. My mediacenter ran ZFS with 512MB RAM for 2TB of storage, which didn't matter because all I needed was the actual file playing.
Also: Linux is not BSD. ZFS on BSD especially in the earlier days, was more demanding. Nowadays ZFS is offered as the filesystem for regular desktops when installing FreeBSD.
As to OP question: your use case is not the best for ZFS. You could do it using partitions but your IO performance might be a drama. On the other hand: combining large drives with significantly smaller ones usually will lead to hot spindles (the 4TB drive is likely to be involved with a lot of the IOs).
For ZFS I'd probably partition the 4TB drive and mirror it with the 2TB and 2x1TB drives. You'll sacrifice the 700GB one (which is 350GB after mirrored parity) and end up with 3.7TB usable space.
Or you could go funky and do:
- mirror sdd with a 1.8T partition on sdb
- mirror 600GB on sde, sdf, and sdg with respective partitions on sdb
- mirror 300GB on sde with 300GB on sdf
You'll end up with about 3,9 TB usable space in the pool, all mirrored. It might not even perform much worse as the previous scenario, since ZFS is very random IO-driven due to COW and the 4TB disk will be the determining factor anyway.
RAIDZ1 options are limited because of the 4TB drive. You'll never get more than 1,8TB usable space using RAIDZ1, with worse parity. You will have unprotected 1,8TB + 700GB to play with though.
Honestly: I would not Frankenstein my storage this way :-) For this scenario I'd probably consider btrfs, as you'll want backups anyway if your data is meaningful to you, especially in this scenario. I would recommend no other parity scheme as mirrored parity for btrfs for now.