Posted
by
Soulskillon Sunday December 06, 2009 @12:29PM
from the changing-horses dept.

dnaumov writes "FreeNAS, a popular, free NAS solution, is moving away from using FreeBSD as its underlying core OS and switching to Debian Linux. Version 0.8 of FreeNAS as well as all further releases are going to be based on Linux, while the FreeBSD-based 0.7 branch of FreeNAS is going into maintenance-only mode, according to main developer Volker Theile. A discussion about the switch, including comments from the developers, can be found on the FreeNAS SourceForge discussion forum. Some users applaud the change, which promises improved hardware compatibility, while others voice concerns regarding the future of their existing setups and lack of ZFS support in Linux."

Well, what's stopping people using NexentaStor (non-free) or NexentaOS (free as in beer/speech)? Better yet, Nexenta is OpenSolaris w/ ZFS, etc, but is an Ubuntu LTS 8.04-based distribution. Its always been the best of both worlds. If you have something using ZFS today, you can export the pool, install Nexenta, and reimport, being back up in minutes.

In this case, as with many FOSS projects, the sub-1.0 numbers probably mean "there are still features to be added before we consider our work complete".

I'd change your definition to "before we consider the initial version of our work complete". This is exactly why I mentioned sub 1.0 version number in a piece of free software. It means there is no marketing department requiring bumping up the version number to impress anybody.

So, as you say, the devs themselves don't think it has the capabilities to be granted the 1.0 number. For whatever reasons they feel.

In other words, a 0.8 version might be perfectly stable, just not feature-complete from the author's point of view, and perfetly sufficient for a subset of potential users with less sophisticated needs.

The key word here is "might". It might, it might not. One also has to consider that even if the system does have all the features you want and seems stable, is it being properly tested and maintained? Has it been around long enough for it to count as some indication that the devs aren't going to just give up on it soon? Is there already a community around it?

All of this goes into choosing a sub-1.0 project for something important. This is what I meant. To depend on an early version of a piece of software is too big of a commitment without the proper analysis of these and many other issues, most of which are not related to the features per se.

And, in any case, it is free software. So anyone can fork the project and continue with it. And it seems there is actually a fork of this project to keep it running over FreeBSD.

None of this changes what I said. If whoever is using it and worried about its future did consider this issues, good for them. If not, well...

Or, they don't care. Changes in major release number often mean incompatible features. I'd have given a lot, for example, for OpenSSL to use a sane numbering system and release "0.97" as "9.7", and "0.98" as "9.8". Or the idiots over at CPAN who release version 1.1, 1.2, 1.21, 2.2105, then 1.3.

"I don't want to be inflammatory, but having "concerns regarding the future of their existing setups" when using a piece of free software in version 0.7 for something as important as data storage?"

You are kidding, right?

First, the meaning of version numbers is purely dependent on the project. There are plenty of pieces of software that were fine to use in production with version numbers less than 1.0, and there are plenty of pieces of software with larger version numbers (e.g. every other Linux kernel version) that should not be run in production. FreeNAS extremely stable.

Second, even if the version of the FreeNAS that people used was not stable, it is based on a solid OS, filesystem, file services, web server, etc., that are all quite reliable in production, so even if FreeNAS 0.7 had a problem, the problem would be with some UI or scripting, not with the ability to store and serve data, and the data itself would not be at risk. The reality, of course, is that FreeNAS is one of the more mature, reliable NAS projects, so it doesn't matter much that you don't like the number 0.7.

The real problem here isn't that people were stupid to use FreeNAS, but that the FreeNAS developer is making a controversial move of switching the underlying OS to one that doesn't support a previously supported, and very popular, filesystem. And since data storage is the point of a NAS, that change is unpopular with the users of FreeNAS. The same change would have the same impact whether it was numbered 0.7, 1.0 or 3.1. For example, look at the upgrades from XP (AKA Windows 5) to Windows 7, which requires a data backup and restore, and reinstallation of all applications. I suppose you could attempt to argue that XP was too unstable to rely on, and that upgraders were stupid to have relied on such an immature OS, but that isn't what actually happened. Just as with FreeBSD, the developer chose to make a somewhat incompatible upgrade, and the users have to deal with the fallout.

From my perspective, my data, which is all in ZFS, is more valuable than the particular web/admin tools used to serve the data, so it means that FreeNAS 0.8 won't be an option for me. Luckily there are plenty of options, and migration is easy.

Well, Linux does have problems dropping or corrupting bits, and can't detect corrupted bits like ZFS can, which means that silent data corruption is possible.

It's not necessary that Linux causes the corruption. The problem is corruption occurs that Linux can't fix / deal with reasonably, or the way Linux filesystems work is high-risk, and ext3 fsck is horrible, in that data loss or inconsistency of I/Os results and cannot be corrected, despite the fact the filesystem is "journaled": in fact, ext3 journaling is not true journaling, by default, ext3 operates in the less-reliable journal_data_ordered, and not journal_ordered; thus, only metadata is journaled, and data corruption is likely if power or access to storage is disrupted.

The ext3 / ext4 filesystems do not live up to the "journalling" promise.

It's happened too many times to count, that I have lost important data, database, or even entire systems due to Ext3 shenanigans, on Debian Etch, Ubuntu, Redhat Enterprise Linux 4, and Redhat Enterprise Linux 5.

Usually how it happens is a kernel panic, power outage, reset (due to system lock-up), or something of that nature occured, and upon boot, the journal is aborted -- however, there is still data corruption after abort of the journal, or even, the abort of the journal fails, and it becomes necessary to manually run fsck, which "tinkers around with the filesystem" trying to make the metadata consistent again.

I have yet to ever have any issues with ZFS-based or NTFS-based systems; they handle it seamlessly.
Windows 2003 or 2008 may show a blue screen once every 2 or 3 years, but the system doesn't require an expert to travel out and manually run chkdsk (Windows equivalent of fsck).
And ZFS handles this quite elegantly....

By the way, even NTFS is ahead of ext3 [microsoft.com] in some ways, in this regard, as far as self-healing is concerned.

Just because it runs Linux doesn't mean the physical disks are magically immune to common issues that effect all storage.

Linux isn't the worst choice for a NAS.
(In fact, I would be really scared of the idea of using NTFS for a NAS).

However, it's just as dishonest to suggest Linux Debian is rock-solid for a NAS as it is to suggest Windows 2000 is.

FreeBSD or Solaris is a really good choice for a NAS.

Systems that utilize certain versions of the Linux kernel can be a good choice, with the right configuration, and right supporting programs installed.

For example, a dedicated NAS appliance, can easily provision its ext3 filesystems using SAFE journalling options, instead of the defaults.

And can also pick just the right kernel version and library versions to be as stable as possible under the supported hardware list...

It's not necessarily good for a NAS to support as much hardware as possible: The Number 1 cause of system crashes is faulty hardware or faulty hardware drivers.

It's best to stick with old hardware and driver code that has been around for 5+ years, without major bugs detected.

Conjecture! I mean, I don't have figures to back this up either, but I do know there is shirtloads of code in a Linux distro with an intact BSD/Apache/MIT license. I am not aware of wholesale re-licensing just for the sake of it.

But there is no point saying "if BSD code was restricted from GPL licensing it would be the other way around" because; 1) that is not the way things are and; 2) the whole point of BSD is it does not have these restrictions.

Where BSD code HAS been incorporated into GPL it has been done to comply with the BSD license, exactly as intended by the author. If they did not want their code to be used they would have selected a more restrictive license.

I don't get where the resentment comes from, but I would hazard a guess that it is BSD users (or fanboys if you will) rather then BSD developers who insist on these cyclical arguments.

Guys, I don't work for Sun (and I think they are in no position to hire people at the moment:-/ ) but you should really drop by to one of their demonstrations to see what they are doing in the storage arena.

Sun has beautiful (technically speaking) NAS devices that allow people to do detailed configuration and troubleshooting using web based point and click GUIs.

Those devices are based on 2 Solaris technologies: ZFS and dtrace.

You can do snapshots, create and share filesystems, find which machines are being pigs with disk usage and for what reason (data or metadata?) all at the click of a mouse.

The important thing is that it is all done with technologies anybody could use, in other words there is nothing stopping the FreeNAS guys, or anybody else, replicating what Sun is doing to offer a non commercial solution when contracted support is not affordable.

I am sure FreeBSD is a great OS (yeah, really) and I appreciate Debian very much, but if there ever was a case of using the wrong tools for the job this would be a sadly good example.