Could be interesting.

@Ghani said in Extend ZFS zpool Volume Size Without Any Data Loss: @scottalanmiller yes rsync not a backup solutions So in a "read back" mode, this tells us that the data stored here isn't important so there isn't really anything to worry about. If you do the expansion and it causes data loss, they can't be upset as they don't see value in the data. This also tells us that the servers shouldn't be there, because if they aren't backed up and they aren't a caching system then you shouldn't have them at all. So there is clearly something wrong.

That list makes hardware RAID sound safer than ZFS, which is probably not quite true. But is the case is that the average implementation of hardware RAID is quite a bit safer than the average implementation of ZFS software RAID. Hardware RAID "handles everything for you" protecting you from most bad decisions. ZFS leaves all the nitty gritty details up to you which makes it super, duper easy to mess something up and leave yourself vulnerable. This is exacerbated by the Cult of ZFS problem and loads of misinformation swirling about its use. So the average person using ZFS is not even remotely prepared for what is needed to use it safely. Some problems that we see people have when using ZFS without fully understanding storage: Believing that ZFS doesn't use RAID (this is extremely common.) Believing that RAIDZ is magic, rather than a brand name, and that normal RAID concerns do not apply. So we often see people implement RAID 5 in reckless, insane situations using "it's RAIDZ" as an excuse as if RAIDZ isn't just RAID 5 - literally just a brand name for RAID 5. Treating common features common to all RAID systems as "unique" and believing that ZFS has feature after feature of protection that makes the need to protect against storage failure unnecessary. Not understanding hot swap and blind swap differences and creating systems that they do not know how to address should a drive fail. Believing that ZFS being magic is not at risk from power loss and failing to protect caches from power issues - something that they are not normally used to dealing with as hardware RAID does this for you. Not understanding the CPU and memory needs of ZFS, especially with features like dedupe and RAIDZ3. Ignoring common RAID knowledge and thinking that using ZFS means not using mirroring technologies.

@dafyre said in Rebuild Time on a 96 Drive RAID 7 Array (RAIDZ3): @scottalanmiller said in Rebuild Time on a 96 Drive RAID 7 Array (RAIDZ3): @travisdh1 said in Rebuild Time on a 96 Drive RAID 7 Array (RAIDZ3): Seems like the perfect case to use RAIN, even if it's within a single system enclosure. @StarWind_Software LSFS, I'm looking at you. @KOOLER I am right in thinking this is the sort of thing LSFS could handle, right? RAIN in a single enclosure rarely does anything that RAID 10 does not. It's effectively all the same at that point (more or less.) If RAID 10 doesn't work, RAIN isn't going to work either (normally.) The issue here is "single enclosure." Wouldn't a properly configured single RAIN node make it easier to grow when it's time to add more storage? I've seen this with Exablox and it was a nice feature! Yes, if you are preparing for scale out. But if you are just doing it within the context of a single node, it doesn't change anything.

I think that it is just ZFS automation.

Sure, mentioned it only for completeness.

Remember, the issue is NOT a violation of the ZFS licensing, it is a violation (supposedly) of the Linux licensing. It is Linux being violated, not ZFS according to the FSF.

@BBigford said in Installing FreeNAS 9.3 on Scale HC3: When you say "in a business capacity"... Do you mean any business or just certain sizes? What is the reasoning? I know you think the FreeNAS community can be very brash/vile at times based on some of your earlier posts to people asking about FN. http://www.smbitjournal.com/2015/07/the-jurassic-park-effect/ Basically you are getting a highly stateful system where support is critical but in a crippled manner compared to just using FreeBSD. You are getting something easy to set up but difficult to support. If anything goes wrong you are in very tough shape. And updates come a bit behind. So you have a number of small issues that all add up to a not very business friendly product.

Could it be going into the nonfree repository and getting a separate license agreement to accept? Canonical made Ubuntu a household name by including other things like this. Anyone else remember having to mess with codecs?

@wirestyle22 said: Do you think this inclusion is worth a legal battle should one ensue? Hard to say, it's a marketing ploy. How much it convinces people based on the Cult of ZFS thing, is unknown. ZFS has a quite religious following, no real technical reason to exist on Linux, so Canonical's play here is to attract that crowd. Whether it is worth it or not, hard to say.

http://www.theregister.co.uk/2016/02/26/canonical_in_zfsonlinux_gpl_violation_spat/

@wirestyle22 said: Question: Isn't the advantage of ZFS modern advances like striping, device pooling, block level CRC, etc? Simple answer: no. Many of those things are equally negatives. Why would you want striping or device pooling in your filesystem?

@Dashrender said: Right, but when you're working with files that large - why bother storing them in a VM - just st.... OK yeah, that goes against the standard practice now.. so we need a VM, even if the whole host is a VM - welp, I guess your stuck with XFS Pretty much. EXT4 is pretty silly for a server of any size, which is why even for desktops RHEL is XFS by default and EXT4 only as an option for advanced users. EXT4's days are pretty much over.

Not really. I'll do it in a few years when it's time to upgrade disks. But most of that will end up in Amazon Cloud Drive soon.

@DustinB3403 said: Scott have you ever looked at this, http://zfsonlinux.org/ Quite a bit

I would recommend looking at StarWind SA for example. That solution fits your requirements perfectly, it will also provide you with HA storage that will ensure the business continuity. As for support, they offer a single point of contact no matter what issue you face, plus the system will be shipped to your site fully preconfigured and pretested.

The FreeNAS community really shows just how important it is to avoid products like FreeNAS. It's built on good tech, but the issues are that the community is horrible, only tiny non-storage expert shops use it and it is broadly misunderstood. FreeNAS doesn't make any of the technology, they just repackage it. So the vendor and their community all lack the basic knowledge of what they have and the stuff that they repeat just gets worse and worse. If this was the FreeBSD community, talking about the same technologies, the answers and approaches would be completely different. Enterprises use FreeBSD every day. They do not use FreeNAS. Once you limit yourself to a "non-expert" product, the idea of using a community for assistance causes a breakdown in dangerous ways.

@MattSpeller said: Learned a lot about RAID from you, it's been fun to learn! Now can you teach me how to get a job as a hardware monkey? Grab a sledge hammer

This one was an easy fix, but that the issue exists at all is a fragility unique to FreeNAS that does not exist if you only use FreeBSD: http://community.spiceworks.com/topic/911053-freenas-database-corrupt

@scottalanmiller Netgear needs to get on here! Who ya know?