That said many people go around that by simply binding the jail against an unsused loopback address (127.0.0.0/8) and then use firewall such as pf to redirect specific ports to given jail, like here http://blog.burghardt.pl/2009/01/multiple-freebsd-jails-shar...
Pray tell, kind sir, from which corner of our good planet does the phrase "warmed my cockles" hail?
http://en.wiktionary.org/wiki/warm_the_cockles_of_someone%27...
When you have a RAID of any kind you need to periodically scrub it, meaning compare data on each drive byte by byte to all other drives (let's assume we are talking just about mirroring). So if you have two drives in an mdadm array and the scrubbing process finds that a block differs from drive A to drive B, and neither drive reports an error, then the scrubber simply takes the block from the highest numbered drive and makes that the correct data, copying it to the other drive. What's worse is that even if you use 3 or more drives, Linux software RAID does the same thing, despite having more info available. On the other hand, ZFS does the scrubbing by checksums, so it knows which drive has the correct copy of the block.
How often does this happen? According to what I have been reading, without ECC RAM and without ZFS, your machines get roughly one corrupt bit per day. In other words, that could be a few corrupt files per week.
My conclusion is that as I am building my NAS, I want ECC RAM and ZFS for things I cannot easily replicate.
https://raid.wiki.kernel.org/index.php/RAID_Administration
How often does this happen? According to what I have been reading, without ECC RAM and without ZFS, your machines get roughly one corrupt bit per day. In other words, that could be a few corrupt files per week.
This is inherent to RAID-5/6. Doesn't really have anything to do with mdadm other than mdadm implements RAID-5/6. And now you probably have a write hole.
mdam is a pain, and doesn't provide block level checksums, so you can easily get silent corruption.
We ran btrfs on top of mdadm, getting both integrity checking and flexibility (although this just tells you that something is wrong).
The big disadvantage is the memory and CPU requirement. If your server has plenty of memory and CPU, I'd use ZFS. If you're running on an ARM NAS with 128MB RAM, I'd use something less fancy.
Word to the wise: Read about the block size of your disks, mine are newer and needed a block size different than the default but I didn't know about it, and now they are slower than they could be. I don't remember details, but you will definitely find it in a cursory search.
I also have an N36L running FreeNAS/ZFS on 4x2TB disks which I've used for about 1.5 years. It finally filled up (SO has data intensive profession) so I was forced to pony up. It's still being used every day and has no signs of failing.
They're both great home servers. I sometimes wish they had more CPU, but for the money, HP is basically giving them away.
[] there are 3 HP microserver versions afaik, the old N40L, the N54L and the new just released Gen8 that is way more expensive (500$ vs 200$)
It's a dream to use and gives me 8TB of usable storage. I can easily hit saturation of the NIC and it's nice and small and quiet, fitting in the bottom corner of my bookshelf.
I was using FreeNAS previously (mainly for the ZFS support to keep my data safe and not spend a bunch on raid controllers) and kept getting bogged down by feeling the need to grok jails. I think jails are terrific in theory, but a pain to work with if you're not intimately familiar with them. Maybe it's just the way it works on FreeNAS, but newly created jails (by default on FreeNAS) were getting a new virtual IP addresses, which really threw me for a loop. Add to that frustration trying to get all the permissions correct just to make a few different services work together started to get really painful.
The drop-dead simplicity of setting up exactly what I had previously on a fresh Ubuntu box with native ZFS port really warmed my cockles.
[0] http://zfsonlinux.org/