search

gmzang / maczfs

Automatically exported from code.google.com/p/maczfs
Other
0 stars 0 forks source link

Found the panic files from my zfs-10a286 2TB drive replace panic #44

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. I have a raidz2 8 drive pool made up of 4 x 1TB drives and 4 x 1.5TB drives
2. I put a new 2TB drive into an available slot on a hot swappable FW800 
enclosure I have and 
issued a zpool replace command

What is the expected output? 
I expected the replace to happen in a timely manner. 

What do you see instead?
I had the black multi-language screen from a panic. The replace appears to be 
running but it has 
been 3 days now.

What version of the product are you using? 
zfs-10a286
iMac: joel$ zfs upgrade
This system is currently running ZFS filesystem version 3.

All filesystems are formatted with the current version.
iMac: joel$ zpool upgrade
This system is currently running ZFS pool version 11.

All pools are formatted using this version.
On what operating system?
10.6.2
Darwin iMac.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 
2009; root:xnu-
1486.2.11~1/RELEASE_I386 i386

Please provide any additional information below.
As it turns out I'm not a very good UNIX administrator and had the pool at 96% 
capacity when I 
tried the replace action.

Original issue reported on code.google.com by joeljami...@gmail.com on 14 Mar 2010 at 1:59

Attachments:

GoogleCodeExporter commented 8 years ago 
Unfortunately, the MacZFS bits aren't up to zpool 11/zfs 3 at the moment. Even 
if they were, they'd be a different codepath (and hence different kernels). 

The 10a286 bits were Apple's last (non-public) binary release; we can't even 
recalculate what it looked like as there are missing files in the CDDL-provided 
source. So there's no way of being able to interpret the changes.

If you run a significantly sized pool, then performance can degrade 
significantly. I wonder in this case whether the machine just ran out of 
memory. Unfortunately, we can't debug this further at this point, since I don't 
have the (non-public) kernel extension bits or have the source to correspond to 
the error.

Original comment by alex.ble...@gmail.com on 20 Jul 2010 at 12:10