@Obsolesce You can watch it on Starwind YouTube channel.

Thanks for the reply, the issue is that sanoid.conf does not send the snapshot to the usb but syncoid does, or does having that template automatic prune the snapshots?

@matteo-nunziati said in Deciding Between Hardware and Software RAID in My FreeNAS Deployment: @saniplastic said in Deciding Between Hardware and Software RAID in My FreeNAS Deployment: @DustinB3403 said in Deciding Between Hardware and Software RAID in My FreeNAS Deployment: metadata metadata? please explain more. The config files where the vm is defined. Do not backup the vm disk only. I suppose he referes to this. I backup with veeam. whole vm files.

Placeholder

@scottalanmiller said in Transparent compression on folders in EXT4/XFS etc?: @dafyre said in Transparent compression on folders in EXT4/XFS etc?: @scottalanmiller said in Transparent compression on folders in EXT4/XFS etc?: @dafyre said in Transparent compression on folders in EXT4/XFS etc?: @scottalanmiller said in Transparent compression on folders in EXT4/XFS etc?: @dafyre said in Transparent compression on folders in EXT4/XFS etc?: Edit: I'm going to put my Zabbix instance on it later and see how it does. Databases should not be compressed! Details as to why databases should not be compressed? Basically because they are always open and written to incrementally. They aren't loaded and rewriteen like most files are. And they tend to be very large, so a very intensive usage pattern. True. But this compression is being done on the Host OS, not inside the Zabbix VM. I wonder what kind of strangeness this can cause. I don't have a lot of traffic on this particular server. That doesn't affect anything. Compression is compression. I'll find out what kind of performance hits I take with it on ZFS. So far, I'm seeing some nice space savings and no problems with anything else.

Way more discussion about this thread in this other thread: https://mangolassi.it/topic/19657/revisiting-zfs-and-freenas-in-2019

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.

@tjatwood109 said in ZFS is Perfectly Safe on Hardware RAID: @scottalanmiller Thanks - I will proceed without using ZFS - I prefer hardware RAID. Tim ZFS is perfectly fine with hardware RAID, if you like ZFS' features otherwise (like zsend is nice) then there's no reason to avoid it. If you don't plan to use any unique features, then XFS is my "go to" choice by default. Very fast, very stable.

@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