Sparse bundle disk image errors reportedly caused by FreeNAS errors

[grahamperrin]

https://github.com/fracai/zfs-rollu...7983#diff-c47c7c7383225ab55ff591cb59c41e6bR49

WARNING: It is also possible for FreeNAS errors to interfer with the AFP service in a way that mimics sparsebundle errors. Before rolling back any datasets, try restarting the AFP service on FreeNAS. Also look for any processes that are in states of "Uninteruptible Sleep" and "pages locked into memory" (D,L respectively). This may indicate a deadlock that will not be recovered byrestarting the AFP service and will require rebooting the FreeNAS machine.

@fracai please is there a FreeNAS or Netatalk bug report for that problem?

(In the FreeNAS area I could not find a matching report.)

 

[fracai]

I'm pretty sure there have been various bugs filed regarding AFP deadlocks and hangs, though I can't pinpoint any right now, and it's hard to say if the specific issue I've seen has been reported. Specifically, I've only seen the DL process state issue a handful of times and other than noting that I was able to get AFP and TimeMachine functional again by rebooting, I don't really have any details regarding how AFP got in to that state.

 

[Glorious1]

I don't get Time Machine unable to work, but it does occasionally decide a backup is bad when it tries to verify it, and then it wants to delete everything and start fresh.

If the FreeNAS errors mentioned above mimic sparsebundle errors, I assume that would cause Time Machine to think the backup is corrupt when it tries to verify it. Then it would set all kinds of flags that the backup is not to be used, and rebooting wouldn't fix that. Could this be causing my problem?

 

[fracai]

Yep, those are similar to the symptoms I've seen. Usually I can get back in business by rolling back to a snapshot that occurred prior to the TimeMachine corruption and backing up again. That saves a ton of time and transfer compared to starting over fresh.