ZFS vs Hardware RAID vs Software RAID vs Anything else

[Eric1024]

Okay so here's the deal. I currently have a RAID 6 array in my main rig consisting of 4x3TB WD Red's running off of an LSI 9260-4i, giving me about 5.5TB of usable space. I've been pretty happy with it so far but I'm in the process of ripping my entire dvd, blu-ray, and music collection onto it and it's filling up. Quickly. I guess it's just poor planning on my part, but I only got the -4i version of the card, limiting me to 4 drives, thinking I couldn't possibly ever fill up 6TB of space. Well I'm quickly approaching that point and I'd like to move my drives out of my main rig and into a server, but my question is this: What should I do for a storage system? Should I get a SAS port multiplier such as this one from intel http://www.newegg.com/Product/Product.aspx?Item=N82E16816117207, or should I ditch hardware raid entirely and use a solution like ZFS or something else?

Any help would be appreciated. (:

[cpuxtech]

If I were you I would base my system off of a hardware solution and get possibly the SAS multi or something like that. I would do a hardware based solution if I were you

[cpuxtech]

If I were you I would base my system off of a hardware solution and get possibly the SAS multi or something like that. I would do a hardware based solution if I were you

It would be worth looking into ZFS and weighing the results out and all, but for a server and or personal rig I wold go with a hardware solution

[Rain]

I recommend ZFS. To use ZFS, you do not need any super expensive RAID controllers (HBAs + SAS Expanders will give you all the ports you will ever need), which makes it much cheaper than a hardware solution.

Also, with a hardware RAID solution, the RAID controller becomes a single-point-of-failure. If it craps out and you cannot get one with the same underlying controller, it will be extreamly hard (if not impossible) to pull data from the array. ZFS does not have this problem. Because it is a type of "software RAID", even if your Motherboard or HBA(s) die you simply need to find a computer with enough SATA ports and boot the system on that to recover data. (Or just replace the broken component in the storage rig and be back up and running in no time at all).

An IBM M1015 will cost you ~$100 on eBay at the moment. Flash it to IT (Initiator-Target) mode to bypass all of the Hardware-RAID functionality and it becomes a cheap SAS HBA. You can then expand the 8 ports to 24 (or more) with the Intel SAS Expander you linked if you need to.

[Eric1024]

I just took a look at flexRAID and it looks good and simple, which I like, but I like the fact that ZFS is free and has caching abilities.

I think what I'm going to do is run ZFS on some version of linux and run my media server off of that. I'm gonna be honest though, I'm not familiar with linux at all, so can one of you perhaps suggest which version of linux I should use?

Thanks for the responses btw (:

[azeotrope]

Don't use ZFS if you're going for linux. ZFSonlinux has no support in mainline and is not as fast or stable as its BSD counterpart. YMMV depending on your kernel and things may break due to little support. If you plan on adding drives in the future in the case that you run out of space again, mdraid or flexraid are better choices since the arrays can be grown if need be. ZFS cannot grow the actual array, only the storage pool. If you decide to go the BSD route for ZFS, then make sure your hardware has good support. Anything Intel should be fine.

As for which distro to use, it depends on how much you want to learn. Ubuntu server is a fair choice, however don't expect it to teach you anything about linux. Anyone who starts off with ubuntu won't learn much, since everything is already set up for you. This is not really a good thing, especially when things go wrong and you know nothing about your system. If you do want to learn, then learn by doing. Set up a minimal install from scratch, such as debian netinstall, arch or gentoo.

[IdeaStormer]

Well more drives equates to more SATA/SAS connections needed. It all really depends how much money and time you want to invest in it. From the sound of it you need to move to Cloud storage, mainly because it will be cheaper in the long run, the problem with it is you'll need a decent connection for it to be reasonably useable. If you want to do it yourself (all on your server/drives) you will need to buy an additional RAID card eventually or bigger drives as your space will only grow unless you just dump the idea of backing up your DVD's. As un-sexy as it is I would burn them to a second DVD and place them somewhere safe, cheaper and you'll have the backup.

ZFS is great but unless you have decent hardware its a fricken nightmare and slow, sure it works but still a pain and you will need to invest some long hours setting up and planning so you don't end up needed to re-configure it down the road.

[Eric1024]

I definitely do not want to use cloud storage. I want full hardware and software control of my media server. I think I'm going to end up just sticking with raid 6 (I already have the raid card and 4 drives) and using a sas port expander. Perhaps I'll switch to flexRAID in the future, but you guys have definitely talked me out of ZFS.

[azeotrope]

NZFS is a totally different take on ZFS. NZFS has almost all advantages of ZFS while patching almost all the disadvantages of ZFS as well. Should be out in the Spring I believe. Looks very interesting so far

http://www.openegg.org/2013/02/12/a-...nt-raid-traid/

I'd be very sceptical about a couple of guys writing a filesystem by themselves, cosidering how much R&D went into ZFS from Oracle. An ext4 corruption bug was found only because google runs thousands of implementations of it on their drives, so I don't even want to think about the bugs that will occur on this and will be misdiagnosed as a hardware issue. Not to mention that the low level stuff would have to run in userspace in both linux and windows, so it will be inherently slower than windows storage spaces, mdraid and zfs running in the kernel.

[Eric1024]

Wow, I'm gonna have to spend some time reading that later. Do you know if NZFS will let you add drives to an array that's already built?

[Rain]

ZFS runs fine on Linux, many people use it (including me). The ZFSonLinux port is a kernel module (runs in kernel space, not user-space like the FUSE implementation); it performs great, is actively developed, and is well supported. The only reason it hasn't been merged with the Linux kernel is because of licensing inconsistencies between CDDL and GNU.

If you don't trust ZFS on Linux, just use a NAS-based BSD distro like FreeNAS. It makes it dead-simple to setup with a nice web-interface for monitoring and management. Even if you don't want to use a pre-configured distro and set it up yourself, FreeBSD is easy to get use to if you already know your way around the *nix shell; it is very, very similar.

NZFS seems sketchy; its in private beta, but I would never jump on a new file system or software RAID implementation until it has been around long enough for the serious bugs to surface and get fixed.

[Eric1024]

ZFS runs fine on Linux, many people use it (including me). The ZFSonLinux port is a kernel module (runs in kernel space, not user-space like the FUSE implementation); it performs great, is actively developed, and is well supported. The only reason it hasn't been merged with the Linux kernel is because of licensing inconsistencies between CDDL and GNU.

If you don't trust ZFS on Linux, just use a NAS-based BSD distro like FreeNAS. It makes it dead-simple to setup with a nice web-interface for monitoring and management. Even if you don't want to use a pre-configured distro and set it up yourself, FreeBSD is easy to get use to if you already know your way around the *nix shell; it is very, very similar.

NZFS seems sketchy; its in private beta, but I would never jump on a new file system or software RAID implementation until it has been around long enough for the serious bugs to surface and get fixed.

Damn, so many conflicting opinions. The thing I'm worried about is not being able to easily add drives in the future with ZFS. Any chance you could shed some light on how adding drives works with ZFS? Thanks.

[IdeaStormer]

ZFS runs fine on Linux, many people use it (including me). The ZFSonLinux port is a kernel module (runs in kernel space, not user-space like the FUSE implementation); it performs great, is actively developed, and is well supported. The only reason it hasn't been merged with the Linux kernel is because of licensing inconsistencies between CDDL and GNU.

If you don't trust ZFS on Linux, just use a NAS-based BSD distro like FreeNAS. It makes it dead-simple to setup with a nice web-interface for monitoring and management. Even if you don't want to use a pre-configured distro and set it up yourself, FreeBSD is easy to get use to if you already know your way around the *nix shell; it is very, very similar.

NZFS seems sketchy; its in private beta, but I would never jump on a new file system or software RAID implementation until it has been around long enough for the serious bugs to surface and get fixed.

Eric1024, what you are looking for is available but not for cheap. Most storage companies support adding or growing their storage arrays on the fly and hot! But those systems are rather costly. One system that is rather reasonable but a black box (closed) is Drobo, again its a closed solution so you're not going to be able to tinker with it other than adding and removing drives.

[Rain]

Damn' date=' so many conflicting opinions. The thing I'm worried about is not being able to easily add drives in the future with ZFS. Any chance you could shed some light on how adding drives works with ZFS? Thanks.[/quote']No RAID solution easily supports the addition of drives in the future. ZFS kinda supports it, but how it works is a bit different.

You can do it one of two ways:

1) Replace all of the drives in the existing pool with bigger drives, one by one, resilvering ("Rebuilding") in between. Once the last drive is swapped out, the pool automatically grows. I would never recommend this method.

2) Conceptually harder to understand, but here we go:

Assume you have a RAIDZ2 pool of 8 drives. It will look something like this: (RAIDZ2 is like RAID6)

        NAME                                 STATE     READ WRITE CKSUM

zfs1 ONLINE 0 0 0

raidz2-0 ONLINE 0 0 0

drive1 ONLINE 0 0 0

drive2 ONLINE 0 0 0

drive3 ONLINE 0 0 0

drive4 ONLINE 0 0 0

drive5 ONLINE 0 0 0

drive6 ONLINE 0 0 0

drive7 ONLINE 0 0 0

drive8 ONLINE 0 0 0

To grow this pool, 8 more identically sized drives would need to be added; doubling the amount of space but not increasing the redundancy.

The resulting pool would look like: (A stripe across two RAIDZ2/RAIDZ6 volumes)

        NAME                                 STATE     READ WRITE CKSUM

zfs1 ONLINE 0 0 0

raidz2-0 ONLINE 0 0 0

drive1 ONLINE 0 0 0

drive2 ONLINE 0 0 0

drive3 ONLINE 0 0 0

drive4 ONLINE 0 0 0

drive5 ONLINE 0 0 0

drive6 ONLINE 0 0 0

drive7 ONLINE 0 0 0

drive8 ONLINE 0 0 0

raidz2-1 ONLINE 0 0 0

drive9 ONLINE 0 0 0

drive10 ONLINE 0 0 0

drive11 ONLINE 0 0 0

drive12 ONLINE 0 0 0

drive13 ONLINE 0 0 0

drive14 ONLINE 0 0 0

drive15 ONLINE 0 0 0

drive16 ONLINE 0 0 0

The problem with this method is that half of the data (assuming you filled up the original pool) is on raidz2-0 and can still only survive 2 drive failures. Likewise, new data added to the pool will live on raidz2-1 and can only survive 2 drive failures. You can refactor the data (I do not remember how to perform this operation off the top of my head); refactoring will stripe the existing data across the new and old vdevs.

Here is what I think the best growth method is: Put together a big pool upfront; as big as you can afford. Then, instead of slowly growing it, save your money until you can buy enough new drives for a new pool/volume. The benefits to this method is that say you continue to grow you single pool/volume until it gets to 100TB one day down the road. Now, imagine a few drives crap out. As explained above, it is possible that you could lose the entire volume if the dead drives crapped in the right places. Now, with a multi-volume setup, you would only lose a few TB in comparison. Also, rebuilds, scrubs/consistency checks, ect will take forever on larger and larger pools where-as with multiple smaller pools, rebuilds will be faster and you will still be able to access the data on other pools while a rebuild is taking place.

[Eric1024]

ZFS runs fine on Linux, many people use it (including me). The ZFSonLinux port is a kernel module (runs in kernel space, not user-space like the FUSE implementation); it performs great, is actively developed, and is well supported. The only reason it hasn't been merged with the Linux kernel is because of licensing inconsistencies between CDDL and GNU.

If you don't trust ZFS on Linux, just use a NAS-based BSD distro like FreeNAS. It makes it dead-simple to setup with a nice web-interface for monitoring and management. Even if you don't want to use a pre-configured distro and set it up yourself, FreeBSD is easy to get use to if you already know your way around the *nix shell; it is very, very similar.

NZFS seems sketchy; its in private beta, but I would never jump on a new file system or software RAID implementation until it has been around long enough for the serious bugs to surface and get fixed.

@IdeaStormerJorge Thanks for the info. I'm learning a ton in this thread, thanks to all of you in fact. I've looked at the Drobo and other NAS's but I'd prefer to have my network storage be an entire computer that I have much more control of.

[Eric1024]

Damn' date=' so many conflicting opinions. The thing I'm worried about is not being able to easily add drives in the future with ZFS. Any chance you could shed some light on how adding drives works with ZFS? Thanks.[/quote']No RAID solution easily supports the addition of drives in the future. ZFS kinda supports it, but how it works is a bit different.

You can do it one of two ways:

1) Replace all of the drives in the existing pool with bigger drives, one by one, resilvering ("Rebuilding") in between. Once the last drive is swapped out, the pool automatically grows. I would never recommend this method.

2) Conceptually harder to understand, but here we go:

Assume you have a RAIDZ2 pool of 8 drives. It will look something like this: (RAIDZ2 is like RAID6)

        NAME                                 STATE     READ WRITE CKSUM

zfs1 ONLINE 0 0 0

raidz2-0 ONLINE 0 0 0

drive1 ONLINE 0 0 0

drive2 ONLINE 0 0 0

drive3 ONLINE 0 0 0

drive4 ONLINE 0 0 0

drive5 ONLINE 0 0 0

drive6 ONLINE 0 0 0

drive7 ONLINE 0 0 0

drive8 ONLINE 0 0 0

To grow this pool, 8 more identically sized drives would need to be added; doubling the amount of space but not increasing the redundancy.

The resulting pool would look like: (A stripe across two RAIDZ2/RAIDZ6 volumes)

        NAME                                 STATE     READ WRITE CKSUM

zfs1 ONLINE 0 0 0

raidz2-0 ONLINE 0 0 0

drive1 ONLINE 0 0 0

drive2 ONLINE 0 0 0

drive3 ONLINE 0 0 0

drive4 ONLINE 0 0 0

drive5 ONLINE 0 0 0

drive6 ONLINE 0 0 0

drive7 ONLINE 0 0 0

drive8 ONLINE 0 0 0

raidz2-1 ONLINE 0 0 0

drive9 ONLINE 0 0 0

drive10 ONLINE 0 0 0

drive11 ONLINE 0 0 0

drive12 ONLINE 0 0 0

drive13 ONLINE 0 0 0

drive14 ONLINE 0 0 0

drive15 ONLINE 0 0 0

drive16 ONLINE 0 0 0

The problem with this method is that half of the data (assuming you filled up the original pool) is on raidz2-0 and can still only survive 2 drive failures. Likewise, new data added to the pool will live on raidz2-1 and can only survive 2 drive failures. You can refactor the data (I do not remember how to perform this operation off the top of my head); refactoring will stripe the existing data across the new and old vdevs.

Here is what I think the best growth method is: Put together a big pool upfront; as big as you can afford. Then, instead of slowly growing it, save your money until you can buy enough new drives for a new pool/volume. The benefits to this method is that say you continue to grow you single pool/volume until it gets to 100TB one day down the road. Now, imagine a few drives crap out. As explained above, it is possible that you could lose the entire volume if the dead drives crapped in the right places. Now, with a multi-volume setup, you would only lose a few TB in comparison. Also, rebuilds, scrubs/consistency checks, ect will take forever on larger and larger pools where-as with multiple smaller pools, rebuilds will be faster and you will still be able to access the data on other pools while a rebuild is taking place.

Thanks for the reply! I'm using 3TB drives at the moment so switching to higher capacity drives isn't much of an option, but I guess I could do it.

So say I have 4x3TB drives in RAIDz2 (which is similar to raid6, right?), it will get me about 6TB of storage, correct? But say I want to upgrade, and I add another 4x3TB drives. Would that get me only another 6TB of storage or would I get a full 12TB more space?

Also, one last question. Say I wanted to upgrade a second time for more space. Would I now need 8x3TB drives or just another 4x3TB drives?

I appreciate the help (:

[Eric1024]

NZFS is a totally different take on ZFS. NZFS has almost all advantages of ZFS while patching almost all the disadvantages of ZFS as well. Should be out in the Spring I believe. Looks very interesting so far

http://www.openegg.org/2013/02/12/a-...nt-raid-traid/

@azeotrope that's a good point. I probably won't be using it but it is interesting.

[Rain]

Damn' date=' so many conflicting opinions. The thing I'm worried about is not being able to easily add drives in the future with ZFS. Any chance you could shed some light on how adding drives works with ZFS? Thanks.[/quote']No RAID solution easily supports the addition of drives in the future. ZFS kinda supports it, but how it works is a bit different.

You can do it one of two ways:

1) Replace all of the drives in the existing pool with bigger drives, one by one, resilvering ("Rebuilding") in between. Once the last drive is swapped out, the pool automatically grows. I would never recommend this method.

2) Conceptually harder to understand, but here we go:

Assume you have a RAIDZ2 pool of 8 drives. It will look something like this: (RAIDZ2 is like RAID6)

        NAME                                 STATE     READ WRITE CKSUM

zfs1 ONLINE 0 0 0

raidz2-0 ONLINE 0 0 0

drive1 ONLINE 0 0 0

drive2 ONLINE 0 0 0

drive3 ONLINE 0 0 0

drive4 ONLINE 0 0 0

drive5 ONLINE 0 0 0

drive6 ONLINE 0 0 0

drive7 ONLINE 0 0 0

drive8 ONLINE 0 0 0

To grow this pool, 8 more identically sized drives would need to be added; doubling the amount of space but not increasing the redundancy.

The resulting pool would look like: (A stripe across two RAIDZ2/RAIDZ6 volumes)

        NAME                                 STATE     READ WRITE CKSUM

zfs1 ONLINE 0 0 0

raidz2-0 ONLINE 0 0 0

drive1 ONLINE 0 0 0

drive2 ONLINE 0 0 0

drive3 ONLINE 0 0 0

drive4 ONLINE 0 0 0

drive5 ONLINE 0 0 0

drive6 ONLINE 0 0 0

drive7 ONLINE 0 0 0

drive8 ONLINE 0 0 0

raidz2-1 ONLINE 0 0 0

drive9 ONLINE 0 0 0

drive10 ONLINE 0 0 0

drive11 ONLINE 0 0 0

drive12 ONLINE 0 0 0

drive13 ONLINE 0 0 0

drive14 ONLINE 0 0 0

drive15 ONLINE 0 0 0

drive16 ONLINE 0 0 0

The problem with this method is that half of the data (assuming you filled up the original pool) is on raidz2-0 and can still only survive 2 drive failures. Likewise, new data added to the pool will live on raidz2-1 and can only survive 2 drive failures. You can refactor the data (I do not remember how to perform this operation off the top of my head); refactoring will stripe the existing data across the new and old vdevs.

Here is what I think the best growth method is: Put together a big pool upfront; as big as you can afford. Then, instead of slowly growing it, save your money until you can buy enough new drives for a new pool/volume. The benefits to this method is that say you continue to grow you single pool/volume until it gets to 100TB one day down the road. Now, imagine a few drives crap out. As explained above, it is possible that you could lose the entire volume if the dead drives crapped in the right places. Now, with a multi-volume setup, you would only lose a few TB in comparison. Also, rebuilds, scrubs/consistency checks, ect will take forever on larger and larger pools where-as with multiple smaller pools, rebuilds will be faster and you will still be able to access the data on other pools while a rebuild is taking place.

In the first upgrade you would add another 4x3TB drives. You would go from 6TB of space to 12TB of space. The second upgrade you would, again, add another 4x3TB drives. This would bring you from 12TB of space to 18TB of space. The amount of drives you add to expand the array each time is equal to the number of drives you started with.

Also, another worthy thing to make note of: Because ZFS is itself a filesystem, you don't have to do any funky partition expansion when you add the new drives. ZFS takes care of this for you.

[Eric1024]

Damn' date=' so many conflicting opinions. The thing I'm worried about is not being able to easily add drives in the future with ZFS. Any chance you could shed some light on how adding drives works with ZFS? Thanks.[/quote']No RAID solution easily supports the addition of drives in the future. ZFS kinda supports it, but how it works is a bit different.

You can do it one of two ways:

1) Replace all of the drives in the existing pool with bigger drives, one by one, resilvering ("Rebuilding") in between. Once the last drive is swapped out, the pool automatically grows. I would never recommend this method.

2) Conceptually harder to understand, but here we go:

Assume you have a RAIDZ2 pool of 8 drives. It will look something like this: (RAIDZ2 is like RAID6)

        NAME                                 STATE     READ WRITE CKSUM

       zfs1                                 ONLINE       0     0     0

         raidz2-0                           ONLINE       0     0     0

           drive1                           ONLINE       0     0     0

           drive2                           ONLINE       0     0     0

           drive3                           ONLINE       0     0     0

           drive4                           ONLINE       0     0     0

           drive5                           ONLINE       0     0     0

           drive6                           ONLINE       0     0     0

           drive7                           ONLINE       0     0     0

           drive8                           ONLINE       0     0     0

To grow this pool, 8 more identically sized drives would need to be added; doubling the amount of space but not increasing the redundancy.

The resulting pool would look like: (A stripe across two RAIDZ2/RAIDZ6 volumes)

        NAME                                 STATE     READ WRITE CKSUM

       zfs1                                 ONLINE       0     0     0

         raidz2-0                           ONLINE       0     0     0

           drive1                           ONLINE       0     0     0

           drive2                           ONLINE       0     0     0

           drive3                           ONLINE       0     0     0

           drive4                           ONLINE       0     0     0

           drive5                           ONLINE       0     0     0

           drive6                           ONLINE       0     0     0

           drive7                           ONLINE       0     0     0

           drive8                           ONLINE       0     0     0

         raidz2-1                           ONLINE       0     0     0

           drive9                           ONLINE       0     0     0

           drive10                          ONLINE       0     0     0

           drive11                          ONLINE       0     0     0

           drive12                          ONLINE       0     0     0

           drive13                          ONLINE       0     0     0

           drive14                          ONLINE       0     0     0

           drive15                          ONLINE       0     0     0

           drive16                          ONLINE       0     0     0

The problem with this method is that half of the data (assuming you filled up the original pool) is on raidz2-0 and can still only survive 2 drive failures. Likewise, new data added to the pool will live on raidz2-1 and can only survive 2 drive failures. You can refactor the data (I do not remember how to perform this operation off the top of my head); refactoring will stripe the existing data across the new and old vdevs.

Here is what I think the best growth method is: Put together a big pool upfront; as big as you can afford. Then, instead of slowly growing it, save your money until you can buy enough new drives for a new pool/volume. The benefits to this method is that say you continue to grow you single pool/volume until it gets to 100TB one day down the road. Now, imagine a few drives crap out. As explained above, it is possible that you could lose the entire volume if the dead drives crapped in the right places. Now, with a multi-volume setup, you would only lose a few TB in comparison. Also, rebuilds, scrubs/consistency checks, ect will take forever on larger and larger pools where-as with multiple smaller pools, rebuilds will be faster and you will still be able to access the data on other pools while a rebuild is taking place.

Sorry I commented before you finished writing the post. Makes a lot of sense now, thank you.

[Eric1024]

You seem to be getting overwhelmed by all this. Well, don't be. FlexRAID will work just fine for your purposes and is really easy to set up. Adding and removing drives is very simple as well.

After everything that people have said and the other stuff I have read, I'm tending to agree with you.

[Rain]

You seem to be getting overwhelmed by all this. Well, don't be. FlexRAID will work just fine for your purposes and is really easy to set up. Adding and removing drives is very simple as well.

Apart from adding more disks (because you will purchase more disks down the road) you can always try a few different options before you make a commitment.

[Eric1024]

You seem to be getting overwhelmed by all this. Well, don't be. FlexRAID will work just fine for your purposes and is really easy to set up. Adding and removing drives is very simple as well.

Yeah I am going to try a few things, primarily ZFS, flexRAID, and my current RAID 6 and compare speeds, disk usage efficiency, etc.

[azeotrope]

ZFS runs fine on Linux, many people use it (including me). The ZFSonLinux port is a kernel module (runs in kernel space, not user-space like the FUSE implementation); it performs great, is actively developed, and is well supported. The only reason it hasn't been merged with the Linux kernel is because of licensing inconsistencies between CDDL and GNU.

If you don't trust ZFS on Linux, just use a NAS-based BSD distro like FreeNAS. It makes it dead-simple to setup with a nice web-interface for monitoring and management. Even if you don't want to use a pre-configured distro and set it up yourself, FreeBSD is easy to get use to if you already know your way around the *nix shell; it is very, very similar.

NZFS seems sketchy; its in private beta, but I would never jump on a new file system or software RAID implementation until it has been around long enough for the serious bugs to surface and get fixed.

zfsonlinux is not considered stable by any major distro (not even arch) and no major distro has it in the official repos. ubuntu only has a PPA of it. The reason it's not in mainline is because of licensing, but since the development is much slower than the BSD or solaris version of ZFS linus torvalds and his crew would not merge it even if licensing wasn't an issue. ext4, xfs and even btrfs has WAY more development than zfsonlinux. the zfsonlinux guys have even declared that it is not tuned for performance yet. If you want stability, this isn't the way to go.

[Rain]

ZFS runs fine on Linux, many people use it (including me). The ZFSonLinux port is a kernel module (runs in kernel space, not user-space like the FUSE implementation); it performs great, is actively developed, and is well supported. The only reason it hasn't been merged with the Linux kernel is because of licensing inconsistencies between CDDL and GNU.

If you don't trust ZFS on Linux, just use a NAS-based BSD distro like FreeNAS. It makes it dead-simple to setup with a nice web-interface for monitoring and management. Even if you don't want to use a pre-configured distro and set it up yourself, FreeBSD is easy to get use to if you already know your way around the *nix shell; it is very, very similar.

NZFS seems sketchy; its in private beta, but I would never jump on a new file system or software RAID implementation until it has been around long enough for the serious bugs to surface and get fixed.

It is definitely stable enough for home-use. The only reason it isn't developed as fast as the "standard" Linux file-systems is because it won't ever get merged. The more people who use it, the better because that gives the developers more of a reason to continue. ZFSonLinux is currently on ZFS Pool Version 28. As you can from the Oracle ZPOOL changelogs, the only really significant change has been the addition of ZFS encryption. The ZFSonLinux team haven't jumped in because they have to perfect back-end performance before they add another level of complexity. Unless you're stressing a ZFSonLinux system in a production environment, you will likely never see any problems in home-usage.

Also, note that I didn't say Linux + ZFS was the only option. ZFS on BSD is definitely better, I agree. ZFSonLinux has really come a long way though. Many people do actually use it.

[azeotrope]

ZFS runs fine on Linux, many people use it (including me). The ZFSonLinux port is a kernel module (runs in kernel space, not user-space like the FUSE implementation); it performs great, is actively developed, and is well supported. The only reason it hasn't been merged with the Linux kernel is because of licensing inconsistencies between CDDL and GNU.

If you don't trust ZFS on Linux, just use a NAS-based BSD distro like FreeNAS. It makes it dead-simple to setup with a nice web-interface for monitoring and management. Even if you don't want to use a pre-configured distro and set it up yourself, FreeBSD is easy to get use to if you already know your way around the *nix shell; it is very, very similar.

NZFS seems sketchy; its in private beta, but I would never jump on a new file system or software RAID implementation until it has been around long enough for the serious bugs to surface and get fixed.

If its "stable enough", then why doesn't a single distro support it? even desktop based distros do not. A good way to know how stable something is, is to look at what enterprise uses, and no sysadmin including myself would risk zfsonlinux. stable is stable, there is no such thing as enterprise stable or home use stable. Software bugs do not discriminate.