zpool has disappeared from MacOS but not Solaris (broken header)
54 views
Skip to first unread message
Dan Bethe
Feb 7, 2011, 11:42:30 PM2/7/11
to zfs-macos
Hi guys. I *really* hope some of you get a kick out of this, because
I utterly am *not*. :)
In the final stages of upgrading my system to 8x2TB raidz2, I decided
to switch to a different Mac clone boot manager. By the way, "I
decided to" is usually the phrase you hear from the ADHD hackintosh
crowd with the magical heads, which is usually the only explanation
given for their spontaneously irrational and destructive behavior,
effectively equating to "hey let's ride bikes"! So yeah I succumbed
somehow to some new Mac cloner bling.
Anyway.
I don't know if this is relevant, but fyi, I had accidentally created
my 8x2TB raidz2 using only MBR. I had *started* to do it the proper
way, using GPT and EFI, because Alex said it didn't matter appreciably
to the write performance, if at all. I had run something like this:
for i in {0..7} ; do diskutil partitiondisk /dev/disk${i} GPTFormat
ZFS %noformat% 100% ; done
But at the time of zpool creation, I typed "zpool create big raidz2
disk0 disk1 disk2..." instead of disk0s1. So MacZFS took it upon
itself to overwrite the raw drive with an MBR, and then create a
zpool.
/dev/disk0
#: TYPE NAME SIZE
IDENTIFIER
0: FDisk_partition_scheme *2.0 TB
disk0
1: 0xEE 2.0 TB
disk0s1
Each of these eight drives used to have an orange icon in Disk
Utility, and after running this boot manager, now they have the stock
metallic hard drive icon. Most importantly, 'zpool import -d /dev'
lists none of my main ZFS drives.
All my other drives have HFS+ at the front, and they appear fine in
native MacOS terms. This includes one pair of drives which start with
a bootable RAID 0 of HFS+ MacOS, followed by a RAID 0 of ZFS. That
RAID 0 zpool is still intact, and is recognized as existing, by
MacZFS.
It's like the ZFS driver works, but my whole-drive zpools are *gone*
from MacZFS's view. The OpenIndiana LiveUSB can import it just
perfectly fine, as if nothing is wrong, and I let it scrub 10% of the
zpool. Rebooting back to MacOS still shows the original problem.
So here's a diagram, if that helps.
[ HFS+ MacOS ] drive == ok
[ HFS+ MacOS RAID 0 ] [ ZFS RAID 0 ] drive
+
[ HFS+ MacOS RAID 0 ] [ ZFS RAID 0 ] drive, array == ok
[ ZFS ] == drive not ok
[ ZFS ] drive + [ ZFS ] drive + [ ZFS ] drive, array == not ok
etc
By the way, how do I know if I jacked up my 4k drive boundary
optimization via this MBR setup? I had a *lot* going on at the
time. :-o
Please help. ^_^
I utterly am *not*. :)
In the final stages of upgrading my system to 8x2TB raidz2, I decided
to switch to a different Mac clone boot manager. By the way, "I
decided to" is usually the phrase you hear from the ADHD hackintosh
crowd with the magical heads, which is usually the only explanation
given for their spontaneously irrational and destructive behavior,
effectively equating to "hey let's ride bikes"! So yeah I succumbed
somehow to some new Mac cloner bling.
Anyway.
I don't know if this is relevant, but fyi, I had accidentally created
my 8x2TB raidz2 using only MBR. I had *started* to do it the proper
way, using GPT and EFI, because Alex said it didn't matter appreciably
to the write performance, if at all. I had run something like this:
for i in {0..7} ; do diskutil partitiondisk /dev/disk${i} GPTFormat
ZFS %noformat% 100% ; done
But at the time of zpool creation, I typed "zpool create big raidz2
disk0 disk1 disk2..." instead of disk0s1. So MacZFS took it upon
itself to overwrite the raw drive with an MBR, and then create a
zpool.
/dev/disk0
#: TYPE NAME SIZE
IDENTIFIER
0: FDisk_partition_scheme *2.0 TB
disk0
1: 0xEE 2.0 TB
disk0s1
Each of these eight drives used to have an orange icon in Disk
Utility, and after running this boot manager, now they have the stock
metallic hard drive icon. Most importantly, 'zpool import -d /dev'
lists none of my main ZFS drives.
All my other drives have HFS+ at the front, and they appear fine in
native MacOS terms. This includes one pair of drives which start with
a bootable RAID 0 of HFS+ MacOS, followed by a RAID 0 of ZFS. That
RAID 0 zpool is still intact, and is recognized as existing, by
MacZFS.
It's like the ZFS driver works, but my whole-drive zpools are *gone*
from MacZFS's view. The OpenIndiana LiveUSB can import it just
perfectly fine, as if nothing is wrong, and I let it scrub 10% of the
zpool. Rebooting back to MacOS still shows the original problem.
So here's a diagram, if that helps.
[ HFS+ MacOS ] drive == ok
[ HFS+ MacOS RAID 0 ] [ ZFS RAID 0 ] drive
+
[ HFS+ MacOS RAID 0 ] [ ZFS RAID 0 ] drive, array == ok
[ ZFS ] == drive not ok
[ ZFS ] drive + [ ZFS ] drive + [ ZFS ] drive, array == not ok
etc
By the way, how do I know if I jacked up my 4k drive boundary
optimization via this MBR setup? I had a *lot* going on at the
time. :-o
Please help. ^_^
Daniel Bethe
Feb 8, 2011, 3:30:43 AM2/8/11
to zfs-...@googlegroups.com
By the way, here's some 'zdb' for you if that helps. Thanks, guys.
===
Hossenfeffer:~ dtm$ sudo zdb -l /dev/disk0
Password:
--------------------------------------------
LABEL 0
--------------------------------------------
version=8
name='big'
state=1
txg=282255
pool_guid=11849983899618372757
top_guid=6282600282372245799
guid=8824671748237612096
vdev_tree
type='raidz'
id=0
guid=6282600282372245799
nparity=2
metaslab_array=14
metaslab_shift=32
ashift=12
asize=16003153002496
is_log=0
children[0]
type='replacing'
id=0
guid=15639660508681507650
whole_disk=0
children[0]
type='disk'
id=0
guid=761026885786631126
path='/dev/disk1'
whole_disk=0
DTL=28
children[1]
type='disk'
id=1
guid=11821611813174021595
path='/dev/disk3'
whole_disk=0
not_present=1
DTL=1301
children[1]
type='disk'
id=1
guid=4101988372858212367
path='/dev/disk8'
whole_disk=0
DTL=27
children[2]
type='disk'
id=2
guid=6991906270239885202
path='/dev/disk4'
whole_disk=0
DTL=26
children[3]
type='disk'
id=3
guid=10083192959729976354
path='/dev/disk3'
whole_disk=0
DTL=25
children[4]
type='disk'
id=4
guid=8824671748237612096
path='/dev/disk2'
whole_disk=0
DTL=24
children[5]
type='disk'
id=5
guid=1030746179038249550
path='/dev/disk6'
whole_disk=0
DTL=1302
children[6]
type='disk'
id=6
guid=6882870521017438537
path='/dev/disk7'
whole_disk=0
DTL=1243
children[7]
type='disk'
id=7
guid=11299509371824603245
path='/dev/disk5'
whole_disk=0
DTL=1284
--------------------------------------------
LABEL 1
--------------------------------------------
version=8
name='big'
state=1
txg=282255
pool_guid=11849983899618372757
top_guid=6282600282372245799
guid=8824671748237612096
vdev_tree
type='raidz'
id=0
guid=6282600282372245799
nparity=2
metaslab_array=14
metaslab_shift=32
ashift=12
asize=16003153002496
is_log=0
children[0]
type='replacing'
id=0
guid=15639660508681507650
whole_disk=0
children[0]
type='disk'
id=0
guid=761026885786631126
path='/dev/disk1'
whole_disk=0
DTL=28
children[1]
type='disk'
id=1
guid=11821611813174021595
path='/dev/disk3'
whole_disk=0
not_present=1
DTL=1301
children[1]
type='disk'
id=1
guid=4101988372858212367
path='/dev/disk8'
whole_disk=0
DTL=27
children[2]
type='disk'
id=2
guid=6991906270239885202
path='/dev/disk4'
whole_disk=0
DTL=26
children[3]
type='disk'
id=3
guid=10083192959729976354
path='/dev/disk3'
whole_disk=0
DTL=25
children[4]
type='disk'
id=4
guid=8824671748237612096
path='/dev/disk2'
whole_disk=0
DTL=24
children[5]
type='disk'
id=5
guid=1030746179038249550
path='/dev/disk6'
whole_disk=0
DTL=1302
children[6]
type='disk'
id=6
guid=6882870521017438537
path='/dev/disk7'
whole_disk=0
DTL=1243
children[7]
type='disk'
id=7
guid=11299509371824603245
path='/dev/disk5'
whole_disk=0
DTL=1284
--------------------------------------------
LABEL 2
--------------------------------------------
failed to read label 2
--------------------------------------------
LABEL 3
--------------------------------------------
failed to read label 3
Hossenfeffer:~ dtm$
Alex Blewitt
Feb 8, 2011, 5:40:09 AM2/8/11
to zfs-...@googlegroups.com, zfs-...@googlegroups.com
It looks like your disk is in the middle of a replacement operation. I'd leave that running until it is finished before trying to fix that.
You may be able to import the disk under osx with zpool import id, where that's one of the guide below.
If you want to stamp back data you'll need to run the diskutil setup, as before. It's hit or miss whether this will work. Given zfs stores pool metadata at both start and en of disk, even if you overwrite the first section then it may survive. When you reinitialise the disk, just don't zero or format a partition. A scrub should then fix any metatdata needed.
Given that you're in untested territory, I'd have a backup of the pool to hand before attempting this.
Alex
Sent from my iPhone 4
Daniel Bethe
Feb 8, 2011, 1:32:27 PM2/8/11
to zfs-...@googlegroups.com
Well that's another oddity, Alex. Before my current problem, when performing a replacement into the raidz2, the resulting resilver will complete but the replacement operation will not complete. Then I did some combination of 'zpool scrub' again and waiting another 8 hours or so, and maybe a 'zpool clear', and maybe a reboot, or something, and it finally set the replaced drive to ONLINE status. This second time that I did it, the resilver finished, and a subsequent scrub would finish after about 30 seconds, but the replacement never finished. Then I had my little boot manager accident.
So, the drive *is* replaced; it just doesn't know it. :(
Furthermore, I can't do any form of 'zpool import', not even by ID. MacZFS
can't see anything but that RAID 0 zpool which is at the *end* of the two drives which begin with HFS+ RAID 0. All full-drive zpools do not exist.
Further-er-more, my original diskutil setup doesn't apply, because MacZFS replaced it in the first place with an MBR setup.
It's not like this:
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *90.0 GB disk2
1: EFI
209.7 MB disk2s1
2: Apple_HFS Vertex2 89.7 GB disk2s2
It's like this:
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *2.0 TB disk3
1: 0xEE 2.0 TB
disk3s1
So I don't know how to overwrite that! Is it a matter of partition type or what does MacZFS require in order to identify that a zpool exists? It seems that it should be more rigorous.
I guess I may as well scrounge up the space to copy the data off, using Solaris, and then rebuild the partitions and raidz2. Just start over.
This is all on MacOS 10.6.5 32-bit and ZFS 74.0.1, by the way.
Thanks!
From: Alex Blewitt <alex.b...@gmail.com>
To: "zfs-...@googlegroups.com" <zfs-...@googlegroups.com>
Cc: "zfs-...@googlegroups.com" <zfs-...@googlegroups.com>
Sent: Tuesday, February 8, 2011 4:40:09
Subject: Re: [zfs-macos] zpool has disappeared from MacOS but not Solaris (broken header)
Daniel Bethe
Feb 8, 2011, 6:38:32 PM2/8/11
to zfs-...@googlegroups.com
Colleagues. Hackers. Friends.
Once in a while, we are afforded the opportunity to really consider what life is about. To ask ourselves the deepest questions of our souls, our passion, our fear. To face the abyss, and to have the abyss stare back into *us*. To ponder why we are here! What does it all mean? Why do we try?
Why not give it all up and move to a mountain in Tibet? Live on a strict diet of apples, ponder humanity, come back, and found a computer company in a garage.
I mean, that's what you do when something hits the fan and you suddenly find that all of your data is apparently gone, and you crash into various murderous existential cycles, installing various test platforms, and then
you realize you only needed to prepend your commands with 'sudo' the whole time.
So yeah, for some reason I guess the permissions had changed on my zpool drives such that I needed to use 'sudo'. Even after having initialized the kext.
So, never mind, thanks to JasonRM for patient troubleshooting help in IRC as usual, and thanks again, Alex. :-}
Hossenfeffer:~ dtm$ zpool import
pool: backuppool
id: 405846273152058149
state: FAULTED
status: The pool is formatted using an incompatible version.
action: The pool cannot be imported. Access the pool on a system running newer
software, or recreate the pool from backup.
config:
backuppool UNAVAIL newer version
disk10s4 ONLINE
disk11s4 ONLINE
Hossenfeffer:~ dtm$ sudo zpool import
pool: zpool9
id: 419585314761547782
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
zpool9 ONLINE
disk9
ONLINE
pool: backuppool
id: 405846273152058149
state: FAULTED
status: The pool is formatted using an incompatible version.
action: The pool cannot be imported. Access the pool on a system running newer
software, or recreate the pool from backup.
config:
backuppool UNAVAIL newer version
disk10s4 ONLINE
disk11s4 ONLINE
pool:
big
id: 11849983899618372757
state: DEGRADED
action: The pool can be imported despite missing or damaged devices. The
fault tolerance of the pool may be compromised if imported.
config:
big DEGRADED
raidz2 DEGRADED
replacing DEGRADED
disk1
ONLINE
11821611813174021595 FAULTED corrupted data
disk8 ONLINE
disk6 ONLINE
disk3 ONLINE
disk0 ONLINE
disk5
ONLINE
disk7 ONLINE
disk4 ONLINE
Daniel Bethe
Feb 8, 2011, 6:46:25 PM2/8/11
to zfs-...@googlegroups.com
And btw, like I said, I had made two physically separate backups of all critical
data before having made the system change that I did. Lest you think I'm daft!
And I apologize to any actual ADHD sufferers for my sarcastic indiscretions with
the terminology in my original post; I was making fun not of those who *suffer*
from ADHD, but those who *enjoy* it ;)
data before having made the system change that I did. Lest you think I'm daft!
And I apologize to any actual ADHD sufferers for my sarcastic indiscretions with
the terminology in my original post; I was making fun not of those who *suffer*
from ADHD, but those who *enjoy* it ;)
Alex Blewitt
Feb 9, 2011, 8:52:40 AM2/9/11
to zfs-...@googlegroups.com, zfs-...@googlegroups.com
On 8 Feb 2011, at 23:38, Daniel Bethe <d...@smuckola.org> wrote:
> So yeah, for some reason I guess the permissions had changed on my zpool drives such that I needed to use 'sudo'. Even after having initialized the kext.
When ZFS auto mounts a drive (because it sees the ZFS partition type) that gets run as root. That's distinct from mounting a FS (even root FS) from an already known pool. So to do a zpool import, you need to be root.
You will find you need to import the pool manually at next startup as well since the zfs.util which does the probing won't recognise it without the partition type.
Alex
Reply all
Reply to author
Forward
0 new messages