Closed zfsfan closed 10 years ago
ilovezfs
commented
10 years ago Your disks are probably just renumbered, and the panic is unrelated.
sudo zpool export tank
sudo zpool import tankOn a side note, why would you use raidz2 with three disks instead of a 3-way mirror?
zfsfan
commented
10 years ago The panic looks like a legitimate bug.
Back to the corruption/failure state.. Yes, it appears my drives were remapped when the reboot occurred. However, I encountered additional issues with attempting to resolve the faulted states on disk3 and disk4. Taking the disks offline, then using 'gpt destroy
Regarding raidz2, I chose raidz2 to test its functionality with the drives I have available.
Is ZFS raidz2 using parity for only detecting errors to place a drive in a failed state, or does it go the extra step and use the parity information to repair a failed read and place them into a degraded state? Does ZFS "repair" the failed read by attempting a store of the fixed data back to the drive? Does ZFS put the drive into a failed state or a degraded state in this scenario?
Seems that ZFS raidz2 could use the parity to survive errors on the remaining two disks, whereas a mirror would have no fallback for correcting errors on the remaining two disks after one fails. Correct?
lundman
commented
10 years ago 0xffffff802e1b91a4
zfs_getattr_znode_unlocked (in zfs) (zfs_vnops_osx_lib.c:350)
zfs_vnop_access (in zfs) (zfs_vnops_osx.c:313)
0xffffff802dffc1d7
https://github.com/openzfsonosx/zfs/commit/73868940d36fb4a31dacd4826ed0d6cf7f15d445
I know we added it in the attempt to fix spotlight (return identical information to hfs+). But since I don't fully understand the API, it might be safer to remove it. We should check for regression though, in case something in Finder really needs that.
ilovezfs
commented
10 years ago @zfsfan There was no need for you to be doing 'zpool offline' or 'gpt destroy' or any of the rest of that. All that was needed was zpool export tank && zpool import tank. If there had been a legitimate need to run gpt destroy, and resilver a device, the correct command is 'zpool replace' to trigger resilvering. Simply onlining a device after destroying the partition table, will not trigger resilvering.
Any kind of redundancy, whether copies = n (with n >= 2), n-way mirrors, or raidz/raidz2/raidz3, will be used to repair incorrect checksums automatically and during scrub.
With three devices, other than experimentation, there is absolutely no reason to use raidz2, which will always consume two devices worth of space in a vdev for parity information, leaving you with n - 2 devices worth of space for data. So when n = 3, n - 2 = 1, meaning you will have one device worth of space available for data. A three-way mirror would also have a data capacity equal to the space of one device, so using raidz2 instead of three-way mirror provides no space advantage, and will only cause resilvering times to much longer than they are with n-way mirrors. Furthermore, raidz2 will provide no additional protection over a three-way mirror. You can lose up to two devices in a raidz2 just as you can lose up to two devices in a three-way mirror.
https://blogs.oracle.com/relling/entry/zfs_raid_recommendations_space_performance https://blogs.oracle.com/roch/entry/when_to_and_not_to http://constantin.glez.de/blog/2010/06/closer-look-zfs-vdevs-and-performance http://constantin.glez.de/blog/2010/01/home-server-raid-greed-and-why-mirroring-still-best
Summary: A pool corrupting kernel panic in the zfs driver during a volume clone via CCC/rsync to a newly created raidz2, using three new drives.
panic(cpu 2 caller 0xffffff802e1bc1c6): "kauth_identity: can't insert record without UID or GID as key"@/SourceCache/xnu/xnu-2422.100.13/bsd/kern/kern_credential.c:1213 Kernel Extensions in backtrace: net.lundman.zfs(1.0)[0EC79B06-3C9F-3529-8450-42222507F310]@0xffffff7faf94c000->0xffffff7fafb55fff dependency: com.apple.iokit.IOStorageFamily(1.9)[9B09B065-7F11-3241-B194-B72E5C23548B]@0xffffff7fae4d3000 dependency: net.lundman.spl(1.0.0)[E94395C5-BE95-36B6-BA13-D00853C9D857]@0xffffff7faf937000
Pool status after this destructive panic:
Hardware: Using three WD 3TB Red drives --> Addonics Port Multiplier SATA-> eSATA Bridgeboard --> Sonnet Tempo 6G ExpressCard --> Sonnet Echo Expresscard Thunderbolt Adapter --> Mac Mini 2011. Using one jHFS+ 2TB WD Green drive on the same bridge board controller mentioned above.
ZFS pool created using OpenZFS_on_OS_X_1.2.7.dmg:
Performed a volume copy via Carbon Copy Cloner version 3.5.4. Source: 2TB WD Green. "/Volumes/TimeWarp2" Destination: ZFS raidz2 "tank/Archive". Carbon Copy Cloner Log:
Panic log reported 15 minutes after the copy started, and reboot: