Exported zpool not possible to import

[plq]

Exported a zpool (tank) through the Terminal over remote ssh. Worked well, folders disappeared in Finder.

Then went to GUI to import tank again, but it could not be found.

Is this the expected behavior from FreeNAS, or is it an area for improvement?

FreeNAS machine is not accessible after reboot after the export operation. Again,
is this the expected behavior?

BR, peter

 

[ProtoSD]

Because you exported it from the command line, the database still has the settings/thinks its still online. You'd need to purge the pool from the database before you could re-import it. Currently there is no method to do this unless you know what to purge using sqlite3 from the command line.

As for your system not being accessible after exporting and rebooting, that's a question I'm not sure I can answer. I don't think this should be expected behaviour.

 

[plq]

1. "Because you exported from the command line ..."
Yes, I did. And I was not aware that FreeNAS keeps a database of the ZFS configuration in a sqlite database.

Where is that database kept?

The only discs in my system are the zfs data discs, so they are not a logical place. The only other place for storage is the
USB plug (which could potentially account for the failure to boot).

The reason for using the command line, was that there is (I did not find one) no way to export a zpool from FreeNAS using
the GUI, so CLI is the only alternative.

2. If FreeNAS is dependent on a sqlite database for its operation, how can a pool be exported to a different platform?

My assumption (which may be very wrong) was that the file system (the zfs data discs contained enough information among
themselves for a different platform (with zfs implemented) to recognize the zfs data, and make it possible to import the
file systems and pool to a different platform.

The conclusion here then is that CLI can not be used for any operation that potentially alters the information in the
sqlite db. If this is the was FreeNAS operates then I think it is important that this is brought up such that you can avoid
using both CLI and the WEBGui.

3. If you choose to avoid the WebGui alttogether, is operation of FreeNAS possible from the CLI only? Or does an import
of a pool depend on the same sqlite db?

BR, peter

 

[Durkatlon]

If you're going to use just the CLI you might as well run FreeBSD instead of FreeNAS :D.

The later versions definitely have an export option in the GUI; I am running BETA4 and it has it. Go to Storage>Volumes>View All Volumes. You'll see an "Export" button next to your volume. Perhaps you can re-import through the CLI and then try exporting it through the GUI again?

The SQLite database is in /data/freenas-v1.db by the way.

 

[plq]

I'll definitely try with a later version.

But I am still confused about the database. I suppose the /data/freenas-v1.db is on a RAM disc, not on a ZFS disc
or on the memory stick (USB stick in my case).

If this is so, how does the database survive a Power off/Power on sequence?

BR, and thanks for answering, peter

 

[Durkatlon]

No, the database is on the USB stick. Check out the output of mount:

Code:

[durk@nanotube ~]$ mount
/dev/ufs/FreeNASs1a on / (ufs, local, read-only, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/md0 on /etc (ufs, local)
/dev/md1 on /mnt (ufs, local)
/dev/md2 on /var (ufs, local)
/dev/ufs/FreeNASs4 on /data (ufs, local, soft-updates)
... more ZFS related mounts ...
[durk@nanotube ~]$

As you can see /data is mounted from FreeNASs4 which is a partition on the USB stick. It is also mounted read/write unlike the rest of the file system (except the parts that are on memory disks, again from the mount output this would be /etc, /mnt and /var).

 

[woger]

Just bumping in ;-)
I have exported a raidz zpool from within freenas 8.01 RC AMD64 which ended up the same way. Volume has dissapeared in freenas but disks are not available. I get an alert "WARNING: The volume backup (ZFS) status is " . I destroyed the zpool with ssh but the disks are still not found by freenas.

 

[plq]

Durkation,
Many thanks for your insights!
I have reformatted the USB stick and tried to import the zpool from the command line before doing anything else.
Zpool import reports /tank as being available to import.
However, when I issue the command zpool import tank the command reports back as follows:
cannot mount '/tank': failed to create mountpoint

So I guess it is back to wiping the discs (no material loss at this point, other than the time required) and starting all over.

I have checked the Sun documentation, and their description is that once exported, the computer system has no knowledge
of what was in the exported file system. This is confirmed by what happened when I issued the zpool import command, as
it was evident from the sounds coming from the box that the system was reading the discs in order to find what was
available.

In a separate message I have suggested a Q&A for the FAQ section to inform users of how FreeNAS works in this respect
(e.g. use the WEB GUI exclusively, or the CLI, but not both)

BR, peter

 

[ProtoSD]

Peter, all you need to do is an 'Auto Import' from the GUI and it will create the mount point and your volume will be 'imported' and accessible again, NO DATA LOSS.

 

[ProtoSD]

2. If FreeNAS is dependent on a sqlite database for its operation, how can a pool be exported to a different platform?

FreeNAS just uses the database to manage its settings and doesn't keep any settings that prevent you from exporting ZFS volumes and importing them under a different platform. It just gets mixed up when it finds disks with a signature saying they're part of a volume and or vice versa.

 

[woger]

I have found the problem and put a workaround here:
http://forums.freenas.org/showthread.php?2290-Exported-Volume-now-the-drives-are-gone.

The problem is, when you export the volume, freenas doesn't remove everything from it's database. I removed it manually and the disk reappear again.