Aaron Botsis пишет: > Hello, I've hit this same problem. > > Hernan/Victor, I sent you an email asking for the description of this > solution. I've also got important data on my array. I went to b93 hoping > there'd be a patch for this. > > I caused the problem in a manner identical to Hernan; by removing a zvol > clone. Exact same symptoms, userspace seems to go away, network stack is > still up, no disk activity, system never recovers. > > If anyone has the solution to this, PLEASE help me out. Thanks a million in > advance.
Though it is a bit late, I think it's still may be useful to describe a way out of this (prior to fix for 6573681). When dataset is destroyed, it is first being marked inconsistent. If the destroy cannot complete for whatever reason, upon dataset open ZFS discovers that it is marked inconsistent and tries to destroy it again by calling appropriate ioctl(), if destroy succeeds, then it pretends that dataset never existed, if it fails, it tries to roll it back to previous state - see lines 410-450 here http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzfs/common/libzfs_dataset.c But since ioctl() was unable to complete, it was no easy way out. Idea was simple - avoid attempting to destroy it again, and proceed right to rollback part. Since it was a clone, it was definitely possible to roll it back. So i simply added test for environment variable to 'if' statement on line 441, and it allowed to import pool. my 2 cents, Victor > > Aaron > >> Well, finally managed to solve my issue, thanks to >> the invaluable help of Victor Latushkin, who I can't >> thank enough. >> >> I'll post a more detailed step-by-step record of what >> he and I did (well, all credit to him actually) to >> solve this. Actually, the problem is still there >> (destroying a huge zvol or clone is slow and takes a >> LOT of memory, and will die when it runs out of >> memory), but now I'm able to import my zpool and all >> is there. >> >> What Victor did was hack ZFS (libzfs) to force a >> rollback to "abort" the endless destroy, which was >> re-triggered every time the zpool was imported, as it >> was inconsistent. With this custom version of libzfs, >> setting an environment variable makes libzfs to >> bypass the destroy and jump to rollback, "undoing" >> the last destroy command. >> >> I'll be posting the long version of the story soon. >> >> Hernán > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
