This is most likely a very silly question and I suspect the answer is no. I currently have 4 disks setup as a ZFS RAID Z volume set on a Mac using maczfs (can't remember version but recent). Can I directly import them into FreeNAS without losing any data? It's not really a big deal if I can't as I'll just backup the data and recreate the volume however I was wondering if this would be possible.
-
Important Announcement for the TrueNAS Community.
The TrueNAS Community has now been moved. This forum will now become READ-ONLY for historical purposes. Please feel free to join us on the new TrueNAS Community Forums
Compatibility with Mac ZFS
- Thread starter leebee96
- Start date
- Status
D
dlavigne
Guest
Post the output of zpool get version.
- Joined
- Feb 15, 2014
- Messages
- 20,194
No problem with ZFS itself, but the middleware may be expecting certain partition layouts which would not be present on pools made on other systems.
fracai
Guru
- Joined
- Aug 22, 2012
- Messages
- 1,212
Are you talking about things like swap partitions? In one installation I have, FreeNAS hasn't had an issue there. I'd be interested if there are other concerns, but I haven't seen any partition layouts that seem particularly unique. Do you mean the ".system" dataset? Wouldn't FreeNAS just create that if it's missing, but required?
The middlware makes assumptions about how your pools are layed out (among 99% of the other things FreeNAS does). You *can*/*should* be able to mount a pool in FreeNAS so long as it's compatible with FreeNAS, but it is *not* recommended you keep it that way.
There's been sporatic reports of pools suddenly failing with no explained reason. They seem to share a common factor... the pools weren't created by FreeNAS. So take the risk, or don't. But *I* wouldn't mount a pool in FreeNAS with the expectation of keeping it that way for much longer than it takes to migrate the data to a pool that is made by FreeNAS.
There's been sporatic reports of pools suddenly failing with no explained reason. They seem to share a common factor... the pools weren't created by FreeNAS. So take the risk, or don't. But *I* wouldn't mount a pool in FreeNAS with the expectation of keeping it that way for much longer than it takes to migrate the data to a pool that is made by FreeNAS.
danb35
Hall of Famer
- Joined
- Aug 16, 2011
- Messages
- 15,504
Why do you think this?
jgreco
Resident Grinch
- Joined
- May 29, 2011
- Messages
- 18,680
So that the devs can have the nightmare joys of people doing stupid/clever/bad/horrifying disk tricks and then get blamed when it blows up.
fracai
Guru
- Joined
- Aug 22, 2012
- Messages
- 1,212
Because ZFS is a common filesystem, not a unique feature of FreeNAS. I get that in most cases each operating system supplies their own implementation of ZFS, but I've never seen it advertised as FreeNAS's ZFS. Plus, the whole feature flags paradigm was intended to allow the open source ZFS implementations to move past the closed source Oracle version and allow for divergence and compatibility among the different forks. I think ultimately it just feels weird/odd/wrong for an implementation to make decisions that break compatibility with others. Aside from implementation bugs, why would a ZFS volume created on one implementation be incompatible with another implementation? Do I need to worry that tar/gzip/etc files created on other platforms won't be compatible with FreeNAS? Are there assumptions made for other "standard" tools that lead to incompatibility with the FreeNAS implementation?
If this is actually the direction FreeNAS is headed, why not just change the name to avoid any ambiguity? At the least I'd think these "assumptions" need to be documented so users can account for them. Simply referring to how the "pools are layed out" and "sporadic reports" doesn't clarify much.
I'm certainly not expecting anyone to support "disk tricks". I'm just suggesting that it's a reasonable goal that a pool created on a system in a standard way should be readable on any other system that supports the same version and flags. I'd expect more headache from calling it ZFS but not being compatible than I would from being compatible and saying you don't support "tricks".
I note that the OpenZFS FAQ states that pools should be compatible across operating systems as long as the flags are compatible. I also note that iX is listed on the site as using OpenZFS and has participated in the Developer Summit. If iX doesn't want to present the perception that pools are compatible they should probably request to be removed from and stop participating in the project that says they're compatible.
jgreco
Resident Grinch
- Joined
- May 29, 2011
- Messages
- 18,680
The filesystem itself is compatible, but the appliance makes assumptions - in the case of FreeNAS, especially assumptions about layout, etc.
In much the same way many Linux based SoC NAS boxes are based off ext3, you can theoretically move disks between them and they might be readable, but the exports and metadata and all that are not compatible between devices.
That doesn't mean ext3 is a bad choice but rather that the world isn't as simplistic as you wish it was.
In much the same way many Linux based SoC NAS boxes are based off ext3, you can theoretically move disks between them and they might be readable, but the exports and metadata and all that are not compatible between devices.
That doesn't mean ext3 is a bad choice but rather that the world isn't as simplistic as you wish it was.
jgreco
Resident Grinch
- Joined
- May 29, 2011
- Messages
- 18,680
Yes, it's called the manual.
In any case, an example of a problem is that if you pull a pool off a Solaris system and then drop it onto a FreeNAS system, it'll probably be readable, but if you try to do something like a disk replacement using the FreeNAS UI, it'll fail, because a Solaris admin probably used the entire disk for the pool element and FreeNAS uses a (smaller) partition, meaning the replacement device gets formatted into being a slightly smaller disk. Or, there may be issues with how the disk device is identified - FreeNAS likes to identify devices by gptid. And your FreeNAS box won't magically export the things your Solaris box had exported, even if ZFS has some hooks that theoretically allow for that kind of thing.
And going the other way around (modern FreeNAS -> Solaris) is more difficult, because the FreeNAS ZFS is fairly "modern" and probably has feature flags other older ZFS variants don't, which translates to "that won't work."
In any case, an example of a problem is that if you pull a pool off a Solaris system and then drop it onto a FreeNAS system, it'll probably be readable, but if you try to do something like a disk replacement using the FreeNAS UI, it'll fail, because a Solaris admin probably used the entire disk for the pool element and FreeNAS uses a (smaller) partition, meaning the replacement device gets formatted into being a slightly smaller disk. Or, there may be issues with how the disk device is identified - FreeNAS likes to identify devices by gptid. And your FreeNAS box won't magically export the things your Solaris box had exported, even if ZFS has some hooks that theoretically allow for that kind of thing.
And going the other way around (modern FreeNAS -> Solaris) is more difficult, because the FreeNAS ZFS is fairly "modern" and probably has feature flags other older ZFS variants don't, which translates to "that won't work."
fracai
Guru
- Joined
- Aug 22, 2012
- Messages
- 1,212
I'm not aware of the manual pointing out any (non-version related) incompatibilities with pools from other OSs.
And the issues you've pointed out aren't unique to FreeNAS. For one, disks of differing sizes are already a known issue even when trying to replace a drive in a pool that was created with FreeNAS. And the FreeNAS to Solaris example is the same. Feature flags and versions are already handled by the zfs / zpool tools to manage compatibility and divergence. I don't think the way FreeNAS identifies the devices matters for compatibility either. Isn't there metadata on the drives that identify the devices? I know I've seen pools in FreeNAS with devices that weren't labeled with gptid.
To reiterate, I'm looking for something like a known issue where a pool that is created on another system can be imported successfully into FreeNAS (versions and flags being compatible), but the pool will fail because FreeNAS assumes it's "layed out" in a certain way (what does that mean?), but fails to check that it actually is. Something like that would be good to know about (and filed as a bug to be fixed), but aside from references to anecdotes claiming that pool failure was due to a non-FreeNAS pool, I haven't seen any evidence that it's an issue. I haven't tried or needed to import a pool from another system, but shouldn't these issues be clearly documented somewhere?
As far as I can tell, the documentation only identifies pools as being portable among platforms.
http://doc.freenas.org/9.3/freenas_intro.html#zfs-primer
And the issues you've pointed out aren't unique to FreeNAS. For one, disks of differing sizes are already a known issue even when trying to replace a drive in a pool that was created with FreeNAS. And the FreeNAS to Solaris example is the same. Feature flags and versions are already handled by the zfs / zpool tools to manage compatibility and divergence. I don't think the way FreeNAS identifies the devices matters for compatibility either. Isn't there metadata on the drives that identify the devices? I know I've seen pools in FreeNAS with devices that weren't labeled with gptid.
To reiterate, I'm looking for something like a known issue where a pool that is created on another system can be imported successfully into FreeNAS (versions and flags being compatible), but the pool will fail because FreeNAS assumes it's "layed out" in a certain way (what does that mean?), but fails to check that it actually is. Something like that would be good to know about (and filed as a bug to be fixed), but aside from references to anecdotes claiming that pool failure was due to a non-FreeNAS pool, I haven't seen any evidence that it's an issue. I haven't tried or needed to import a pool from another system, but shouldn't these issues be clearly documented somewhere?
As far as I can tell, the documentation only identifies pools as being portable among platforms.
http://doc.freenas.org/9.3/freenas_intro.html#zfs-primer
jgreco
Resident Grinch
- Joined
- May 29, 2011
- Messages
- 18,680
It isn't a "bug to be fixed." The basic technology is generally compatible, but the stuff piled on top is designed to work a certain way. The immense complexity of these software systems leads to all sorts of possible issues. The only truly SAFE pool is one that was created by FreeNAS on FreeNAS for FreeNAS.
I'm not really interested in discussing it further. You're welcome to search and experiment further, of course, but from my point of view it is mostly a nonissue. It's similar to how we mitigate hardware compatibility problems by not doing stupid things like selecting magic hardware.
I'm not really interested in discussing it further. You're welcome to search and experiment further, of course, but from my point of view it is mostly a nonissue. It's similar to how we mitigate hardware compatibility problems by not doing stupid things like selecting magic hardware.
Naaa, the manual isn't the documentation you are looking for. The source code is. That literally, is the only "documentation" that exists. Microsoft doesn't share with you and document in excruciating detail how everything works on their OS, and neither do we.
You want to see the "magic behind the WebGUI", that's where it *all* happens.
You know that solaris does things totally different from FreeBSD? They have a unified memory architecture, and that makes ZFS a wholly different beast. Solaris tunables often don't exist in FreeBSD and vice versa. They often don't work the same because of the memory management between the OSes. Solaris used to basically require "whole disk/unpartitioned" zpools to function properly because the ARC could only handle "whole disks" (or something like that). ZFS on linux has their own recommendations on doing whole disk versus partitioned disks for ZFS. FreeNAS does a 2-partition setup and has decided for you. You also don't have to tell it what sector size to use, because the source code has already decided for you (4k). You have no idea how many decisions have been made *for you* behind your back, because of the WebGUI.
I dare you to install FreeBSD and try to setup SSH with keys, a zpool with proper partition alignment and 4k sector size, create some datasets and share them with NFS and Samba with AD integration, make the permissions work properly in NFS and Samba, and then actually mount that stuff elsewhere and use it to transfer files at LAN saturating speeds. If you've never done it, you'd spend weeks just trying to figure out some of the basics. Nevermind try to handle updates to the OS and the whole other host of very real problems and maintenance that you have to do on the server. I've heard people claim that what they can do in 20 minutes in FreeNAS takes them a week or so to truly set up properly in FreeBSD. I'd wager that 99.99% of us in the forum are probably incapable of setting up a FreeBSD server with the same kind of quality that FreeNAS provides if we were given 3 months to do it. You have no idea how good you have it with FreeNAS. I wouldn't even take the challenge if I was offered.
The *only* thing that various ZFS implementations have in common is the file system structure itself should be compatible. Not always, but *should* (despite feature flags and everything else). If you read around in FreeBSD there are lots of ex-solaris guys that rebuilt their pools in FreeBSD because they were aware of (and often ran into) problems when going cross-platform.
Ok, so pretend a pool is corrupted that came from Solaris and worked in FreeNAS for 2 months. What went wrong? Was it before FreeNAS or after FreeNAS? Was it because of a bug in the Solaris ZFS code? How are you going to prove that? Do we (as the small entity that is FreeNAS) really want to throw developer resources at a problem that *only* manifests itself when someone tries to move a Solaris pool to FreeNAS?
No, you have to put it in perspective and think about the big picture...
1. We (as a development team) are *much* too small, insignificant, and inexperienced to try to troubleshoot a problem that is very likely the result of something from Solaris' world that went badly or is otherwise incompatible.
2. I don't *want* developers spending stupendous amounts of time trying to troubleshoot those problems. I want them fixing big problems with CIFS, NFS, *our* ZFS bugs, etc. The stuff that we *do* see regularly. To hell with the few people that want to take a pool and go all over the world with it. If they want that kind of flexibility they can go to FreeBSD (see the challenge I mentioned above).
3. This is *not* an issue that is/was/ever will be limited to FreeNAS, FreeBSD, Linux, Solaris, etc.
4. This thread was about Mac ZFS. I never used it, but people that have talked about it in IRC in the past said it was about the worst piece of software they've ever used. Do we really want to be tied to that?
I am also with jgreco that I'm not going to discuss this further. It doesn't matter who wants what and the people that made that decision do not routinely hang out in the forums. In an ideal world ZFS would be compatible and work. But we don't live in that ideal world, and we never will.
You want to see the "magic behind the WebGUI", that's where it *all* happens.
You know that solaris does things totally different from FreeBSD? They have a unified memory architecture, and that makes ZFS a wholly different beast. Solaris tunables often don't exist in FreeBSD and vice versa. They often don't work the same because of the memory management between the OSes. Solaris used to basically require "whole disk/unpartitioned" zpools to function properly because the ARC could only handle "whole disks" (or something like that). ZFS on linux has their own recommendations on doing whole disk versus partitioned disks for ZFS. FreeNAS does a 2-partition setup and has decided for you. You also don't have to tell it what sector size to use, because the source code has already decided for you (4k). You have no idea how many decisions have been made *for you* behind your back, because of the WebGUI.
I dare you to install FreeBSD and try to setup SSH with keys, a zpool with proper partition alignment and 4k sector size, create some datasets and share them with NFS and Samba with AD integration, make the permissions work properly in NFS and Samba, and then actually mount that stuff elsewhere and use it to transfer files at LAN saturating speeds. If you've never done it, you'd spend weeks just trying to figure out some of the basics. Nevermind try to handle updates to the OS and the whole other host of very real problems and maintenance that you have to do on the server. I've heard people claim that what they can do in 20 minutes in FreeNAS takes them a week or so to truly set up properly in FreeBSD. I'd wager that 99.99% of us in the forum are probably incapable of setting up a FreeBSD server with the same kind of quality that FreeNAS provides if we were given 3 months to do it. You have no idea how good you have it with FreeNAS. I wouldn't even take the challenge if I was offered.
The *only* thing that various ZFS implementations have in common is the file system structure itself should be compatible. Not always, but *should* (despite feature flags and everything else). If you read around in FreeBSD there are lots of ex-solaris guys that rebuilt their pools in FreeBSD because they were aware of (and often ran into) problems when going cross-platform.
Ok, so pretend a pool is corrupted that came from Solaris and worked in FreeNAS for 2 months. What went wrong? Was it before FreeNAS or after FreeNAS? Was it because of a bug in the Solaris ZFS code? How are you going to prove that? Do we (as the small entity that is FreeNAS) really want to throw developer resources at a problem that *only* manifests itself when someone tries to move a Solaris pool to FreeNAS?
No, you have to put it in perspective and think about the big picture...
1. We (as a development team) are *much* too small, insignificant, and inexperienced to try to troubleshoot a problem that is very likely the result of something from Solaris' world that went badly or is otherwise incompatible.
2. I don't *want* developers spending stupendous amounts of time trying to troubleshoot those problems. I want them fixing big problems with CIFS, NFS, *our* ZFS bugs, etc. The stuff that we *do* see regularly. To hell with the few people that want to take a pool and go all over the world with it. If they want that kind of flexibility they can go to FreeBSD (see the challenge I mentioned above).
3. This is *not* an issue that is/was/ever will be limited to FreeNAS, FreeBSD, Linux, Solaris, etc.
4. This thread was about Mac ZFS. I never used it, but people that have talked about it in IRC in the past said it was about the worst piece of software they've ever used. Do we really want to be tied to that?
I am also with jgreco that I'm not going to discuss this further. It doesn't matter who wants what and the people that made that decision do not routinely hang out in the forums. In an ideal world ZFS would be compatible and work. But we don't live in that ideal world, and we never will.
- Joined
- Feb 15, 2014
- Messages
- 20,194
I think you've missed the point; OpenZFS, which FreeNAS purports to employ as its ZFS subsystem, is supposed to already do/be this. And yet, the repeated advice from many on these forums is to avoid it at all cost because of "things and whatnot". As I have indicated before in other contexts, this does little to nothing except instill doubt that FreeNAS is actually as stable or as well thought-out as it claims to be. I have an inherent distrust of systems that work fine as long as you don't poke at them; that's high-Q design and not indicative of a robust system.
If people are going to take the time to argue that the FreeNAS developers shouldn't be concerned about interoperability with other OpenZFS systems, then they should at least identify the challenges that make this a costly endeavour. Otherwise it amounts to saying "that's how Dad did it, that's how 'murica does it, and it's worked out pretty well so far." Don't fear change, understand it!
Bidule0hm
Server Electronics Sorcerer
- Joined
- Aug 5, 2013
- Messages
- 3,710
I can see your point of view but on the other side you don't just "poke at the system", you're merging a filesystem with an OS that manage it a bit differently than the other OS. The system can be ultra stable, if you swap the foundations with another a little bit different it'll obviously be less stable suddenly...
The thing is, you're outside of the normal operating area of the system, it wasn't intended for that so the results can't be certain. It's like using ZFS without ECC RAM, you can take that at "poking at the system" and say it's not stable in these conditions but ZFS makes the assumption it can trust the hardware, as soon as you don't respect that it'll backfire...
The thing is, you're outside of the normal operating area of the system, it wasn't intended for that so the results can't be certain. It's like using ZFS without ECC RAM, you can take that at "poking at the system" and say it's not stable in these conditions but ZFS makes the assumption it can trust the hardware, as soon as you don't respect that it'll backfire...
Last edited:
- Joined
- Feb 15, 2014
- Messages
- 20,194
No, I think my point is similar to yours. We do have a standard, which has strayed from being standardized. The naïve engineering solution would be to cover everyone's use cases with a new standard, in our case a generic ZFS pool handler. Of course, in practice, these solutions always cause fragmentation at first and only work if there's a near-universal commitment to them (like microUSB for charging).
It should work, but that doesn't mean everyone worked towards that goal.
- Status
Similar threads
- Locked
