Cannot mount ....: File name too long

[Apollo]

Working of FreeNAS-9.3-STABLE-201509282017, I have been experimenting with the replication from Freenas GUI.
I have plugged in a drive to act as a backup where I have succesfully replicated the content of a dataset.
Everything looks good so far.
However, detaching the drive and mounting it back is not a breeze as it is not mountable under GUI.

Running "zfs import ..." will output the following errors:

Cannot mount "XXXXXXXXXXX": File name too long

"XXX" stand for the datasets names and directory structure.
Overall, the number of characters is only 89 long, by far smaller than the 256 value.

This bug has been reported under and I have added a note to it:
Bug #9834

My backup is pretty much unusable at this point.
This raise the following questions:

- Why Freenas doesn't check for file name length before replication?
- What is the way around to mounting the volume as it currently doesn't exist under /mnt.
- If I can't mount the volume, it doesn't seem possible to recover the snapshots, or is there a way around it?

 

[Apollo]

To add to the previous post, I have tried to replicate this issue using my own replication technique which consist of proceeding via CLI, as follow:

1) I create a manual recursive snapshot of the top-most dataset. It will be called top-most@manual-today and will propagate across the dataset below.
2) I send the recursive snapshot using the snapshot created above. I only use the top-most@manual-today with the following command:
zfs send -R tankA/top-most@manual-today | zfs receive tankB
3) replication will take place starting from the oldest snapshot and will end when all the snapshot prior to and including "top-most@manual-today" have been transmitted.

From that point on, I can detach the drive, then import it again, and voila. With my technique, I still have access to the data that have been replicated.

On the other end, if I use the GUI replication function, the drive cannot be recovered.

So, based on my observation, something in the steps used for GUI based replication is breaking things apart.

 

[Apollo]

Soem more updates:

Going over those results, I noticed I might have overlooked something. In fact I did. It turns out doing CLI replication, I was not using the same dataset as the source so I was one level above in the folder structure. In a few words, the destination dataset was not long enough to cause the issue from occuring.
Creating a dataset with the same name as the source and then performing replication returned the same outcome.
This is good news in a way as the results agrees with Freenas GUI replication behavior.
However this is becoming a reliability issue.
Going quickly through the folder structure arborescence, some files combined with dataset names do exceed the 256 character limit (is this a hard limit or even the correct value?).

Is there a work around to importing a failing volume?
Can ZFS or Freenas or FreeBSD skip over the failing mounts? In the event the disk can be mounted even partially, accessing the snapshot on the unmounted dataset is possible and recovering the entire dataset through replication is also doable.
However, in the event the volume is not mounted at all, I am at loss. Is there a way to force or maybe mount a portion of the disk and access the snapshots?

 

[Apollo]

More updates:

It seems all is not lost:

Even though the volume may not be listed under /mnt after a failed import, it seems executing the following command returns some positive results:

1) From CLI, execute

Code:

 zpool import

2) Execute the following and the name of the missing volume should appear.

Code:

 zpool list

3) Executing the following should return the snapshots listing on the missing volume:

Code:

zfs list -t snapshot -r tank

From there it should be possible to replicate the unmountable datasets into a diferent dataset with a much shorter name.

This needs to be tested to see if this can be reliably reproduced.

 

[Apollo]

This is very strange, I seem to be the only one interacting with this post, very much like talking to myself, but then again, I am not writing this post just for the fun of it, as I know I may have to go through this process and documenting the steps will most likely help a few users along the the line.

Some more updates and workaround:

I can confirm "zpool import" allows accessing the content of the volume without having the need to mount it (meaning , I can manipulate snapshots and dataset).
So, here is what I have found out:

As per my findings, and some comments related to folder and dataset/directory length limits, I can across some FreeBSD stuff related to ZFS and its dataset manipulation.
I have discovered it is possible to rename a dataset (I thought the only way around was to replicate the actual dataset under a diferent name).

Based on the FreeBSD website,

https://www.freebsd.org/doc/handbook/zfs-zfs.html

I can rename a dataset. What will this do for me and my volume you might say. Well, if the reason I cannot mount a volume is related to the length limitation because of the exceedingly long dataset, then it would make sense to rename some of the unmountable dataset such as to reduce the actual length of the dataset.

This is achievable by using the following command:

Code:

zfs rename Volume/this_is_a_very_lengthy_name_for_my_backup_dataset_which_is_going_to_surely_cause_my_volume_to_not_be_mountable_if_I_am_not_careful  Volume/this_is_my_new_smaller_dataset_name

Importing volume again via CLI using:

Code:

zpool import Volume

The import procedure should take place without any issues.
If some dataset still can't be mounted, then reducing the name of any of the dataset will be required.

At the end, it is possible to fix this issue and then being able to have Freenas GUI import the entire volume without it complaining of anything.

So I must say, I fell good about myself for this excellent work of deduction.
And now I can replicate away (for which the newest replication within FREENAS GUI seems to be handling nicely, at last).

Good job Apollo.
Don't mention it, really.
Fine, I won't.
(... I am wrtting to myself???????????? Nah)