Hi folks,
Well, we’ve successfully rolled another good 9.2.1.x point release! Please come and get it from the usual location. Also as usual, the issues we fixed in this release are best described by looking at the list of fixed tickets in the 9.2.1.4 milestone. We improved replication speed, we fixed more issues with CIFS, we brought in some ZFS fixes (addressing the zpool history 100% CPU spin, among other things), and just basically did our best to keep whittling away at the issues that made 9.2.1.3 less than complaint-free.
So, since the bug database does a better job than we ever could of describing what we’ve fixed in 9.2.1.4, let us take this opportunity to talk a bit about the 9.2.1.x series and our plans for 9.2.2!
As most folks have undoubtedly figured out by now, we’ve been putting a substantial amount of effort into evolving the 9.2.1-BRANCH of FreeNAS with this series of 9.2.1.x releases. There are two primary reasons for this:
We took on a bit more than we expected with the Samba3->Samba4 upgrade, especially given how much more stringent Samba4 is about respecting ACLs and, as we’ve come to understand, the kinds of havoc one can create in FreeBSD by mixing ACLs and chmod(1) since they share the same permission space (and Windows likes ACLs, not Unix mode flags). We’ve added a few seat-belts here and there and also fixed some outright bugs, but it’s clear we still have some work to do in documenting how to use Samba4 effectively.
We’re strongly motivated to get the 9.2.1.x series polished to the point where we can stop doing frequent releases for it and give both ourselves and the FreeNAS community a bit of a rest in that regard, allowing the documentation and other resources to catch up while we go to work full-time on FreeNAS 9.2.2!
Which brings us to FreeNAS 9.2.2. Here is some of what we have in store for the next major release of FreeNAS:
Live updates: Explicit downloading and installation of updates (and manually supplying checksums) will become a thing of the past. FreeNAS will update itself like most other commercial products do – by checking in with an update server, downloading any available updates in the background, and then asking the user for an opportune time to apply them. Worry not, we’re not going to reboot without an admin’s express permission, or give them only one type of update server to use (we know many corporate users are behind firewalls or want to run their own update servers) – we’ll be making provisions to make this as non-intrusive, and as secure, as it should be. This is a bigger topic than one post can possibly do justice to, however, so please stay tuned for more details!
NFSv4: Yes, it’s time for NFSv4 support. This will require some fairly substantial NFS sharing UI changes since NFSv4 is a lot more powerful and flexible than NFSv3.
HAST: Fail-over peering is coming to FreeNAS. For more information, see the link. The UI for this will also be fairly substantial, and we look forward to your feedback as the feature starts entering the daily BETA builds of 9.2.2!
Kernel iSCSI: iSCSI is one of FreeNAS’ more popular features (especially for VMWare folks), and this will be a substantial improvement for this service, both from a performance and feature perspective.
We also have a lot of tickets on our plate for 9.2.2 that cover a positively huge number of enhancements to replication (especially in the UI), performance, “fit and finish” and general bug fixes. We’re really looking forward to making major major progress on 9.2.2 over the coming year (and no, before you ask, we don’t have a specific release date yet – that will be announced later), but first we need to get this pesky 9.2.1.x series behind us. 🙂
We hope that you enjoy using 9.2.1.4 as much as we enjoyed making it. Onwards toward 9.2.2.!
– The FreeNAS Engineering Team
