What makes you believe having the same hostid for different non virtualized OS instances hosted in a single physical machine and thus running only once at a time is a dangerous practice ?
I didn't wrote that. You missed the "almost".
I wasn't talking about a file system shared on a network, which would be NFS or CIFS with a NAS anyway, not ZFS or whatever, but about a partition containing a ZFS pool that is used by different OSes on a multi-boot configuration, i.e. once at a time.

Back to your suggestions, you claim ZFS isn't a good choice because "it is not a good 'sharing' file system as it's expected to be only running on one host OS." However, the alternatives you suggest (ReiserFS, FAT32 and NTFS) are also very expected to run on one host OS at a time, and would be quickly destroyed otherwise. Only shared file systems like GFS and OCFS2 support that on Linux but I don't think there is any support for them on FreeBSD.

Well I'm no expert on the difference between export and unmounting in ZFS, but the very fact that you have to use the -f (force) switch to remount screams bad practice to me.

The export and import options were built specifically with migrating ZFS volumes between OSs in mind. So to intentionally avoid that while depending on the volume for your data just strikes me as risky. Particularly on something as complex as ZFS.

Unfortunately I can't find any documentation online (albeit after only a brief search) that goes into the specifics of what happens during a ZFS export, but it is worth baring in mind that ZFS is more than just a file system (in the traditional sense).
In a traditional fs things like the journal transactions are marked completed during the unmount thus come system restart the fs drivers know that each fs write had completed unencumbered (ie there wasn't a power failure). It's reasonably safe to assume that ZFS will do the same during a normal system shutdown. However without documentation stating the difference between umounting and exporting, I wouldn't recommend your method as there's no guarantee that compression, dedupping or even any of the non-fs settings (eg SMB et al) will be written to an internal fs log instead of a log on the OSs own directory structure. Sure, that would be bad practice on the ZFS team, but it's also a huge gamble (ie all of your data) to assume that every "best practice" has been adheared to (after all, ZFS has already made a number of fs experts nervous by bucking a number of trends such as lumping lower level (eg RAID controllers) and high level (eg SMB) in the same fs drivers.

In short, I think it's at least worth raising the question on Oracles forums to see what the difference is between unmount and export. I might be kicking up a s**t storm over nothing, however (in my opinion) forced imported is a large gamble to pay when it's your data at stake.

I didn't. The 'almost' part seemed like a token gesture given the context of the post.
However I was still harsh and the "narrow minded" comment was unnecessary. Sorry.

I know exactly what you were talking about however you didn't read my response correctly. I said if you want a shared ZFS volume then the best practice is a file server. Your method is sharing a file system locally (albeit not simultaneously) using forced imports. My method uses a static ZFS volume with network shares (which could be written into the guests fstab should they want). Both methods ultimately achieve the same result. Granted yours will have better bandwidth but, until the safety of forced imports are cleared up, I feel safer with recommending SMB/SSHFS network shares as opposed to local hostid duplication when sharing ZFS volumes.

After all, the purpose of this thread is to advise, so I personally think it's better to advise best practices than our own experimental hacks (unless of course you have some documentation proving the security of the data using forced imports, which you've not linked to thus far)

You're really not reading what I'm saying properly. I'm not talking about simultaneous OS access, I'm purely talking about one file system that gets auto-mounted across difference OSs at different times. I'm talking about having a dual boot OS with a shared partition. This is easy (in fact common practice) with ReiserFS, FAT32 and NTFS however it's not so easy with ZFS as you have to remember to export the volume with every shutdown.

Also, I never once recommended FAT32. In fact I had a whole rant about who crappy FAT32 is.


I seriously think you're best off moving this discussion to Oracles forums because you seem to be getting your wires crossed as to what people are posting as well as good and bad ZFS practices.

Please read again my suggestion. I don't have to use the "-f" switch to remount because my server has a single hostid shared by OS instances.There is absolutely no risk. This is even the standard way on SPARC hardware where multiple OS instances on a dual/multi boot configuration share the same hostid.
The difference between unmounting and exporting is clear to me. Unmount applies to file systems while export applies to ZFS pools. A prerequisite to an export is all file systems involved are unmounted.
It wasn't a gesture. I certainly recommend other file systems than ZFS to other people and customers depending on the situation. However, this thread is about a file system to be shared between FreeBSD and Linux and ZFS seems to me the best choice.
No problem.
I got it but I was confused about your reference to a NAS (or file server) as you are actualy talking about a SAN (or storage server). Sharing a volume on iscsi or similar is indeed a situation where exporting/importing a ZFS pool located on the volume must be done properly and where my hostid hack (or import -f) would be disastrous. A reiserFS, ext2/3/4, UFS or whatever non shareable file system would equally suffer from the same situation, and do not have, as far as I know, any internal mechanism in place to avoid such a situation, unlike ZFS.
Again, I do not use forced imports for local file systems. Only for USB devices when I forgot to export the file system at shutdown.
These methods are addressing different situations. While I travel a lot with my laptop, I have no mobile NAS.
Although I do not use forced imports in my solution, I have no doubt about the security of data present on a ZFS pool that would be forcefully imported.
An reciprocally, at least something we agree on so this is exactly what I was talking about to, and I explained how to do it with ZFS without the export/import burden on x86 hardware, just like it works naturally on SPARC one.
Just like multiple OSes on a single machine will share the same ethernet addresse(s), there is nothing wrong with having them sharing the same hostid.
I didn't wrote you recommended FAT32, just you were suggesting it as a possible solution, which it always is.

Ok, well this was the crux i was trying to get to the bottom of: whether your method was standard practice or a personal hack.

Up until now I'd never heard of sharing the hostid like that on SPARC systems so was surprised to hear anyone suggest such a method. However assuming you're right it does seem a good solution and reasonable grounds to recommend ZFS.

However I'd still like a link to somewhere you read if you wouldn't mind, not because I want to drag this discussion on with further disagreements but purely to further my own knowledge as you've clearly highlighted gaps in it.

You miss the point. You're loading the ZFS pool in each OS thus (from my experience) you've need to export the pool before importing.
However I wasn't aware of hostid sharing on SPARC being a standard work around.

No, I was talking about a NAS where the host OS manages the fs. Not SAN which would suffer the problems you described.
You can't go around assuming I meant something other that what I stated and then use that to prove a point I never argued.

Genuine question, what difference does CPU architecture make? I know ZFS prefers 64bit to 32bit on x86, but I assumed that was down to the 128bit addressing in ZFS. However I'd expect the CPU to be transparent to the fs (ie a more powerful processor will obviously run quicker, but it wouldn't change the administration handling of the fs). I may be just misunderstanding your point about SPARC, but you discuss it as if SPARC ZFS is a different beast to manage

[/quote]
I didn't even suggest it as a possible solution. Plus now you're just arguing semantics. If you or I suggest a solution, then that's as good as a recommendation (why else suggest it?).

There is not really a method, it is just the way it works on SPARC hardware. The fact the hostid isn't shared by OS instances on x86 is just due to the lack of hardware persistent general purpose storage with BIOS. Just like the Ethernet hardware address is permanently stored in NICs, SPARC main boards are providing a boot PROM and an NVRAM allowing configuration storage. The hostid is just stored there. On x86 hardware, this hostid is stored on the OS file system using an undocumented method (at least until Solaris source code was open sourced in 2005). When you upgrade the OS, whether regular or live upgrade, the hostid is preserved. However, if you install another OS instance along with the first one for dual booting, a new hostid is created. This is a deficiency that is clearly exhibited in the ZFS pool sharing situation.
Here is a blog post that explains how the hostid is stored on x86: http://blogs.sun.com/ambiguous/entry/introducing_myself
No. It is a work around on x86, on SPARC, it is just the way it works. Not sharing the hostid on SPARC would require a hack.Then the vocabulary you choose was confusing. In ZFS terms, a "shared ZFS volume" means a zvol (i.e. a dataset providing a raw device) that can be shared through iscsi to remote client(s).
It makes no difference by itself. The limitation comes from the IBM-PC architecture which hopefully has never be used with SPARC but unfortunately still plague x86 hardware.
Never mind, I was understanding this sentence of yours to mean FAT32 is a possible solution: "reiserfs is supported on both FreeBSD and Linux and would make a better alternative for those who (understandably) don't want to use FAT32."

Interesting stuff (re SPARC). Thank you for taking the time to elaborate, much appretiated

About to go read the link too now...