- Code: Select all
macbookpro08-centrim:~ gjp22$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *750.2 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS swap 32.0 GB disk0s2
3: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF 536.9 MB disk0s3
4: Apple_HFS spare 671.1 MB disk0s4
5: Apple_CoreStorage 99.5 GB disk0s5
6: Apple_Boot Boot OS X 650.0 MB disk0s6
7: Apple_CoreStorage 616.3 GB disk0s7
8: Apple_Boot Boot OS X 134.2 MB disk0s8
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS OS *99.2 GB disk1
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *616.0 GB disk2
1: EFI 209.7 MB disk2s1
2: ZFS 615.7 GB disk2s2
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: zfs_pool_proxy gjp22 *614.2 GB disk3
macbookpro08-centrim:~ gjp22$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
gjp22 338Gi 225Gi 304Gi /Volumes/gjp22
macbookpro08-centrim:~ gjp22$ sudo gpt show /dev/disk3
Password:
start size index contents
0 1199570944
macbookpro08-centrim:~ gjp22$ zfs list
no datasets available
macbookpro08-centrim:~ gjp22$
That use of gpt may be not sane, but it's interesting that the pool/dataset gjp22 (in use by user gjp22 as a home directory) is gone so easily. The typical outcome is spinning wait cursors for nearly everything, including the Force Quit Applications window of loginwindow, and so I force a restart (Command-Control-power on the MacBookPro5,2 with OS X 10.8.2).
Result of sysdiagnose available privately, on request.
Should we expect more resistance from a future ZEVO or ZFS … a busy response, maybe?
(Early adoption of ZEVO in mind, this is probably mistreatment of the adoptee. "Expect the unexpected" and so on.)
Busy state
For some other types of device, business is recognised. An expected response, where a part of disk0 is for startup of an OS:
- Code: Select all
gpt show: unable to open device '/dev/disk0': Resource busy
Cross reference
Whilst I have not reproduced a kernel panic, I assume that careless uses of gpt – maybe plus the mount weirdness described below – were contributory to the (2012.09.23) still waiting on znode … REG ZIL … mds panic that occurred on 2012-10-04.
gpt show versus unmounted volumes
Steps:
- use the unmountDisk verb of diskutil to unmount all volumes of a disk
- use gpt show for that disk.
Expected:
- a show, nothing more.
Actual results:
- a show, and mount of all volumes.
To me, that seems weird. A bug in the OS? (Nothing for gpt in Open Radar.)
Side note: I recall observing that weirdness during a recent screen recording, but don't know whether it was a recording for ZEVO.