> On Mar 22, 2016, at 7:36 AM, Jan Schlien <list....@jan-o-sch.net> wrote: > > I am debugging something similar and opened > https://illumos.org/issues/6779 yesterday. It looks somewhat related, as > it is also a panic in zap_leaf_lookup_closest(), though not during > zfs_unlinked_drain() but from NFS. Second, I also encountered an > all-zero zap_phys_t along the way. > > I cannot do zdb inspection, as the corruption could be mitigated by > slightly increasing the dataset's quota. You could try the same, > depending on your goals.
I can't increase the quota, because in my case the directory has been deleted, and its final deletion is what triggers that zap panic. My customer found something interesting on from ZFS-on-Linux: > I may be off base here, but I came to this bug fix in ZoL that might be > related to the cause of this. > > https://github.com/zfsonlinux/zfs/commit/4254acb05743dc2175ae76f6e15b0785d4b688fd That may have *caused* the corruption. What isn't clear to me is how we can *FIX* such corruption, or at least work around it. That bug appears to not be fixed in illumos-gate. I'm tempted to compile my customer a custom ZFS module that has the lowest-layer ZAP functions return an error instead of ASSERT() when certain conditions are met. I figure it'll be enough for him to mount his currently unmountable dataset, and then transfer files off of it. Thanks, Dan ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
