zfs CLI user new to FreeNAS

[mm_half3]

Hello,

I have been using zfs on Solaris via CLI for quite some time, and have a pretty good set of zfs CLI experience. Just finished burnin of my first FreeNAS system, and started testing migration plans of a Solaris raidz2 data pool to a FreeNAS pool on the new build.

Already ran into a few issues that eliminated the preferred path of migration; replicating the dataset with zfs send/receive snapshots; an oracle patch a few years back created a zfs option set that makes Solaris zfs five incompatible with FreeNAS zfs five when using zfs send/receive commands....plan B was to use rsync, but since I need to move about 19TB of a 29TB pool, the deprecation of rsh type binaries from FreeBSD makes rsync replication a no go with the overhead of the encrypted transfers over ssh.

That left me with plan C, creating the zfs file systems in the Solaris pool on the FreeNAS system, then using ncftp scripts to transfer the data....the unencrypted ftp transfers are faster than the encrypted rsync transfers. Next I created the data pool, and zfs file systems on the FreeNAS system in a ssh terminal, and transferred a few of the smaller zfs file systems in the Solaris pool using rsync to test the transfer rates....this is when I realized the CLI pools are not seen in the GUI, and after some forum searches see that zfs pools created in the the CLI need to be exported out, then imported in, via the gui as volumes....and I see that typically running zfs commands on data pools/volumes is frowned upon in a FreeNAS system, since it could cause things to get out of sync. Ehhh, not what I was hoping for...never been big on administration via gui.... but since I am committed to giving FreeNAS a fair test out, going to try out doing all storage tasks in its GUI administrative interface.

Anyway now for the questions:

- Is the zfs data pool (with about fourteen zfs file systems in it) created from the CLI, exported out from the CLI, then imported into the gui as a volume with fourteen datasets; going to be fine to work with, and can I begin to transfer the data over from the Solaris system, or should I just destroy the volume in the GUI and re-create it and the datasets in the GUI? On first review things generally look fine in the volume & data sets, the only difference seems to be the default mount point moved the volume to mount under /mnt instead of / when it was imported in....but if that can't (or should not) be changed, that is fine.

- What other server administrative tasks should be done via the gui other than storage tasks? I already found out adding users from the CLI does not survive reboots, so user/group administration is another. Or maybe this question should be re-worded to what server administrative tasks can be safely run in a ssh terminal?


Thanks,

 

[danb35]

Really, anything that can be done through the GUI, should be done through the GUI.

 

[Stux]

One of the biggest differences is via the GUI FreeNAS will add partitions via gptid. Another difference is by default FreeNAS will generate a 2GiB swap partition on each disk. Also, there are some default pool creation flags that you might've missed, which might be of no consequence.

Generally working in the CLI is fairly safe, but it helps if you know where/when FreeNAS synchonrizes with the on disk information. And one of the points is when you import, so if you export from CLI, and then import in GUI, it resynchronises.

My advise would be to use the GUI when you can, and when you have to use the CLI.

 

[mm_half3]

O.k. will use the GUI when there is an option to do so; is the consensus that the volumes that were created by importing in the data pools created from the CLI are fine to use? I have about 600GB of data already transferred over from a few of the smaller zfs file systems on the solaris box, and those could be destroyed and re-created pretty easily if need be. The next file systems up have 8TB and 10 TB in them....would hate to have to transfer those over more than once.