Half of my ZFS filesystems are hidden in ZFS-fuse. Here's my story:
So, I love ZFS. I used it for about six months on FreeBSD, but due to it crashing the kernel during heavy inter-filesystem IO load, I tried switching to Solaris 5.10.
That was good, but when I attempted to do an import of my Version 13 pool into its Version 4 version of ZFS, there were some heafty problems. It may have tried to correct the filesystem definitions, I don't know.
Since that version wasn't compatible with my pool, I've now switched to Ubuntu Server 10.4. That version more than supports that of my pool, but I can only see half of my filesystems. The filesystems I can see are the same as those Solaris could see.
Now, despite those filesystems not being preset in a 'zfs list' command, I can still set properties on them and I can even still mount them and read and write files, but they just plain don't show up in 'zfs list'.
I've mounted the major ones, but I'm not sure what other filesystems there are anymore (I have about eight that I can't see).
Anyone have any idea what the heck is going on? I think I might try booting back into FreeBSD 8 (I still have the main boot drive laying around for that) and see if at least it is able to view the filesystems.
I've also done a scrub while in Linux, and it found no errors with any of the data. Oddly, DMA read errors which caused problems on FreeBSD ZFS are reported by Linux, but ZFS-fuse doesn't find an error. That's a topic for another post however.
Instead of Solaris 10, Linux/ZFS-fuse or FreeBSD, I would use the latest dev opensolaris build (build 134 as of today) which has the more up to date ZFS code included to diagnose what the issue might be. Please post the output of "zfs get all 'invisible-filesystem'" to see what property might prevent some of them to show up.
"due to it crashing the kernel during heavy inter-filesystem IO load"
That may not be the the FreeBSD kernel, but the 3+ years bug with ZFS ARC that still persists!
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6522017
(This one is nasty as it will also go out-of-bounds from the VM limits of a hypervisor!)