gmzang / maczfs

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

USB not supported #51

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Turn on drive and let it mount
2. Eject drive
3. Power off drive

What is the expected output? What do you see instead?
In maczfs_72, this would not cause a crash, in maczfs_74 it does.

What version of the product are you using? On what operating system?
MacOS 10.6.4 using maczfs_74

Please provide any additional information below.

Original issue reported on code.google.com by GAGen...@gmail.com on 2 Aug 2010 at 11:17

Attachments:

GoogleCodeExporter commented 8 years ago
Can you provide a diskutil list when the device is attached?

Also, how did you eject the disk? Did you drag-and-drop it to the trash (with 
the eject button), and did OSX say it was unmounted successfully?

Can you try this again, and once you've ejected it, drop into the command 
prompt and do 'zpool list' to see if OSX thinks that the pool is still there?

The cause of the panic is ZFS is trying to still send commands to the pool post 
dismounting, so understanding how/why it's dismounting is the key to finding 
out what's wrong (and more importantly, how to fix it).

Original comment by alex.ble...@gmail.com on 3 Aug 2010 at 6:41

GoogleCodeExporter commented 8 years ago
To unmount it, I did a (right-click)->"Eject puddle" on the disk icon.  Here is 
the information:

garymac:~ gary$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            119.7 GB   disk0s2
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *203.9 GB   disk1
   1:                        EFI                         209.7 MB   disk1s1
   2:                        ZFS puddle                  203.6 GB   disk1s2
garymac:~ gary$ diskutil info /dev/disk1
   Device Identifier:        disk1
   Device Node:              /dev/disk1
   Part Of Whole:            disk1
   Device / Media Name:      Maxtor OneTouch II Media

   Volume Name:              
   Escaped with Unicode:     

   Mounted:                  No

   File System:              None

   Partition Type:           GUID_partition_scheme
   Bootable:                 Not bootable
   Media Type:               Generic
   Protocol:                 USB
   SMART Status:             Not Supported

   Total Size:               203.9 GB (203928109056 Bytes) (exactly 398297088 512-Byte-Blocks)
   Volume Free Space:        Not Applicable

   Read-Only Media:          No
   Read-Only Volume:         Not applicable (no filesystem)
   Ejectable:                Yes

   Whole:                    Yes
   Internal:                 No
   OS 9 Drivers:             No
   Low Level Format:         Not Supported

After I eject it, it still shows up on the zpool list.  Good call!

Original comment by GAGen...@gmail.com on 3 Aug 2010 at 7:04

GoogleCodeExporter commented 8 years ago
I'll try and reproduce with a USB key. ort, does it go away for good then?

Illnmmediately tries to mount it again. If you do a zpool ecport arbirtration 
notices it has gone, tgener if doskng it. Can you do an eject and then wait for 
a while? I wondeeappear to be actually ejectibg the eject doesnt

Original comment by alex.ble...@gmail.com on 3 Aug 2010 at 8:25

GoogleCodeExporter commented 8 years ago
doesn't work so well ...ase ignore typos - on a phone, it doesnt

Original comment by alex.ble...@gmail.com on 3 Aug 2010 at 8:26

GoogleCodeExporter commented 8 years ago
OK, so there's a couple of interesting behaviours going on here.

1) When I try to eject it, it claims that it's on a disk with 11 other 
partitions. However, it's picking up ZFS pools that are on my system, and if I 
do 'eject all', it attempts to unmount all the other ZFS pools, which is 
clearly wrong.

2) When I do eject it, the filesystem is unmounted. However, the pool is not 
exported; so any removal triggers a crash.

At this point, the workaround is to do an export first before ejecting. It's 
also unclear as to why this worked before - there hasn't been any code changes 
(that I know of) that would affect this issue. I'll have to debug by rolling 
back to MacZFS_72 and seeing if I can reproduce there.

I suggest you knock up a quick AppleScript or bash script that does:

#!/bin/bash
diskutil unmount /Volumes/puddle && zpool export puddle && say Puddle can now 
be powered off

(That's assuming that /Volumes/puddle is where you mount it. You might need to 
do the zpool export -f, and/or with 'sudo' privileges, depending on how you've 
set up your system)

Original comment by alex.ble...@gmail.com on 4 Aug 2010 at 8:15

GoogleCodeExporter commented 8 years ago
I tested on MacZFS_72-1-7 (PROJECT:maczfs_72-1-7-g383f329) which I believe is 
the install version that you're referring to. You can verify that's the same 
version by doing the below:

strings /System/Library/Extensions/zfs.kext/Contents/MacOS/zfs | grep maczfs_

Ejecting the disk with Finder simply unmounts the pool; it doesn't export the 
pool as well. I can recreate this same behaviour for _72 as well.

I'm pretty sure, therefore, that doing an eject of the pool on _72 would also 
cause a crash if powered down. And I'm not sure that the behaviour is different 
from the original Apple bits - or if it is, there's a problem at that point.

Ideally we want to trap into the disk-going-away as a zpool export 
automatically, which would fix this problem, but I still see basically the same 
issue with the _72 bits. I also don't see a change to the place that caused the 
panic; which means this is basically the same thing as Issue 3.

Can you recreate on _72 and verify whether zpool list still shows the pool 
present, even after ejecting?

Original comment by alex.ble...@gmail.com on 4 Aug 2010 at 11:16

GoogleCodeExporter commented 8 years ago
Hello,

I have the same problem occurring when ejecting or even plugging a 
zfs-usb-stick. It doesn't happen every time.

The Kernel panic report is the same, I'm using maczfs_74-0-g3ff178c on 10.6.4.

Regards,

Original comment by fguer...@gmail.com on 15 Aug 2010 at 5:17

GoogleCodeExporter commented 8 years ago
I am seeing a similar issue, related to USB. My kernel panic and configuration 
is a bit different... so I'm posting in case it helps narrow the issue.

What steps will reproduce the problem?
 I'm using sparse images for testing purposes, so I don't have to use multiple physical devices. My test that resulted in kernel panic went as follows:

1) Create 8 sparse disk images in Disk Utility, 2GB each
2) Copy those 8 disk images to 3 separate physical devices (one internal disk 
(2 disk images), 2 external USB (2 on one, the other 4 disk images on the last)
3) Mount disk images (double-click) & then use diskutil to create raidz2:

zpool create tank raidz2 disk3s1 disk4s1 disk5s1 disk6s1 disk7s1 disk8s1 
disk9s1 disk10s1

4) enable lzw compression, copy some files, delete those files
5) enable gzip-9 compression, copy some files
6) disconnect external device with 2 disk images (2 LUNs)
7) zpool status showed all devices operating normally
8) try deleting a file from the 'tank' to the desktop, then kernel panic

What version of the product are you using? On what operating system?
- MacZFS-74.0.0
- OS X 10.5.8

***Add'l info***

Here is the OS X kernel panic log:

Wed Nov 24 17:58:28 2010
panic(cpu 1 caller 0x224202B7): "ZFS: I/O failure (write on <unknown> off 0: 
zio 0x6fd2668 [L0 DMU dnode] 4000L/e00P DVA[0]=<0:1857cf000:1800> 
DVA[1]=<0:1804e800:1800> fletcher4 lzjb LE contiguous birth=205 fill=27 
cksum=e1a85c3f95:1c91eea6ce351:22ceabbb68a9502:f601acb9eb6f6587): error " 
"5"@/Users/alex/Projects/mac-zfs/usr/src/uts/common/fs/zfs/zio.c:918
Backtrace (CPU 1), Frame : Return Address (4 potential args on stack)
0x2294be58 : 0x12b4c6 (0x45f91c 0x2294be8c 0x13355c 0x0) 
0x2294bea8 : 0x224202b7 (0x22432980 0x22432974 0x22432a08 0x22430fe4) 
0x2294bf18 : 0x2241e444 (0x6fd2668 0x499d400 0x2e351b71 0x92b) 
0x2294bf58 : 0x22423d8d (0x6fd2668 0x499d400 0x1129ca 0x22430f28) 
0x2294bfc8 : 0x1a14fc (0x2ae23b0 0x0 0x1a40b5 0x30e1048) 
Backtrace terminated-invalid frame pointer 0
      Kernel loadable modules in backtrace (with dependencies):
         com.bandlem.mac.zfs.fs(74.0.0)@0x223c5000->0x2243cfff

BSD process name corresponding to current thread: kernel_task

Mac OS version:
9L31a

Kernel version:
Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; 
root:xnu-1228.15.4~1/RELEASE_I386
System model name: Macmini2,1 (Mac-F4208EAA)

System uptime in nanoseconds: 10948108121084
unloaded kexts:
com.parallels.kext.prl_usb_connect  3.0 2150.92060 - last unloaded 10753786281631
loaded kexts:
com.parallels.kext.prl_usb_connect  3.0 2150.92060 - last loaded 10691981792147
com.bandlem.mac.zfs.fs  74.0.0
org.virtualbox.kext.VBoxNetAdp  3.1.6
org.virtualbox.kext.VBoxNetFlt  3.1.6
org.virtualbox.kext.VBoxUSB 3.1.6
org.virtualbox.kext.VBoxDrv 3.1.6
com.Cycling74.driver.Soundflower    1.3
com.parallels.kext.prl_vnic 3.0 2150.92060
com.parallels.kext.prl_netbridge    3.0 2150.92060
com.parallels.kext.prl_hypervisor   3.0 2150.92060
com.parallels.kext.prl_hid_hook 3.0 2150.92060
com.apple.filesystems.autofs    2.0.2
com.apple.iokit.IOBluetoothSerialManager    2.1.9f10
com.apple.driver.DiskImages 199
com.apple.driver.AppleUpstreamUserClient    2.7.5
com.apple.Dont_Steal_Mac_OS_X   6.0.3
com.apple.driver.AppleHDA   1.7.1a2
com.apple.driver.AppleIRController  113
com.apple.driver.AppleIntelGMA950   5.4.8
com.apple.iokit.AppleYukon2 3.1.13b2
com.apple.driver.AudioIPCDriver 1.0.6
com.apple.driver.AirPort.Atheros    320.16.2
com.apple.driver.AppleHDAController 1.7.1a2
com.apple.iokit.IOFireWireIP    1.7.7
com.apple.driver.ACPI_SMC_PlatformPlugin    3.4.0a17
com.apple.driver.AppleLPC   1.3.1
com.apple.driver.AppleIntelIntegratedFramebuffer    5.4.8
com.apple.driver.CSRUSBBluetoothHCIController   2.1.9f10
com.apple.driver.AppleUSBMergeNub   3.5.2
com.apple.iokit.IOUSBMassStorageClass   2.0.8
com.apple.iokit.IOSCSIMultimediaCommandsDevice  2.1.1
com.apple.iokit.SCSITaskUserClient  2.1.1
com.apple.driver.XsanFilter 2.7.91
com.apple.iokit.IOATAPIProtocolTransport    1.5.3
com.apple.driver.AppleUSBHub    3.4.9
com.apple.driver.AppleFWOHCI    3.9.7
com.apple.iokit.IOAHCIBlockStorage  1.2.2
com.apple.driver.AppleUSBEHCI   3.4.6
com.apple.driver.AppleAHCIPort  1.7.0
com.apple.driver.AppleIntelPIIXATA  2.0.1
com.apple.driver.AppleEFINVRAM  1.2.0
com.apple.driver.AppleUSBUHCI   3.5.2
com.apple.driver.AppleRTC   1.2.3
com.apple.driver.AppleHPET  1.4
com.apple.driver.AppleACPIPCI   1.2.5
com.apple.driver.AppleACPIButtons   1.2.5
com.apple.driver.AppleSMBIOS    1.4
com.apple.driver.AppleACPIEC    1.2.5
com.apple.driver.AppleAPIC  1.4
com.apple.security.seatbelt 107.12
com.apple.nke.applicationfirewall   1.8.77
com.apple.security.TMSafetyNet  3
com.apple.driver.AppleIntelCPUPowerManagement   76.2.0
com.apple.BootCache 30.4
com.apple.iokit.IOSerialFamily  9.4
com.apple.driver.DspFuncLib 1.7.1a2
com.apple.iokit.IOAudioFamily   1.6.9fc5
com.apple.kext.OSvKernDSPLib    1.1
com.apple.iokit.IO80211Family   216.1
com.apple.iokit.IOHDAFamily 1.7.1a2
com.apple.iokit.IONetworkingFamily  1.6.1
com.apple.driver.IOPlatformPluginFamily 3.4.0a17
com.apple.driver.AppleSMC   2.3.1d1
com.apple.iokit.IONDRVSupport   1.7.3
com.apple.iokit.IOGraphicsFamily    1.7.3
com.apple.driver.AppleUSBBluetoothHCIController 2.1.9f10
com.apple.iokit.IOBluetoothFamily   2.1.9f10
com.apple.iokit.IOUSBHIDDriver  3.4.6
com.apple.driver.AppleUSBComposite  3.2.0
com.apple.iokit.IOBDStorageFamily   1.5
com.apple.iokit.IOSCSIBlockCommandsDevice   2.1.1
com.apple.iokit.IODVDStorageFamily  1.5
com.apple.iokit.IOCDStorageFamily   1.5
com.apple.iokit.IOSCSIArchitectureModelFamily   2.1.1
com.apple.iokit.IOUSBUserClient 3.5.2
com.apple.iokit.IOFireWireFamily    3.4.9
com.apple.iokit.IOStorageFamily 1.5.6
com.apple.iokit.IOAHCIFamily    1.5.0
com.apple.iokit.IOATAFamily 2.0.1
com.apple.driver.AppleEFIRuntime    1.2.0
com.apple.iokit.IOUSBFamily 3.5.2
com.apple.iokit.IOSMBusFamily   1.1
com.apple.iokit.IOHIDFamily 1.5.5
com.apple.driver.AppleACPIPlatform  1.2.5
com.apple.iokit.IOACPIFamily    1.2.0
com.apple.iokit.IOPCIFamily 2.6

Original comment by aaronhol...@gmail.com on 25 Nov 2010 at 3:04

GoogleCodeExporter commented 8 years ago
Here is the corresponding line in the source code:

https://github.com/alblue/mac-zfs/blob/maczfs_74/usr/src/uts/common/fs/zfs/zio.c
#L912

 * For I/O requests that cannot fail, panic appropriately.
  panic("ZFS: %s (%s on %s off %llx: zio %p %s): error "

The problem is ZFS was still expecting to talk to the drive, and the drive went 
away, so ZFS didn't know what to do. A later version of ZFS (onnv_77, I 
believe) made a property by which you could turn panics into warnings, 
essentially, at the loss of the pool.

The question (in the Raid2 case) was why losing two devices caused that 
problem. Maybe it's to do with a file device on a real device (which by the 
way, you don't need to do - you can use 'mkfile' to create a file instead of a 
sparse device) that caused the issue.

A workaround in the meantime is to zpool offline the devices before ejecting 
the disk, or if it's the only source of the pool info, to zpool export the pool 
prior to ejecting.

Once we get to onnv_72, we'll switch the default failmode to 'continue' which 
should see a reduction in this style of panic - though in the above case it 
suggests that the pool would be marked as inactive for some reason.

Lastly, if you want to create multiple devices on a single external pool, use 
'mkfile' and then just mount those bits e.g. mkfile 100m 
/Volumes/usbdrive/zfsdisk1 - you can then zpool create Pool 
/Volumes/usbdrive/zfsdisk1

Original comment by alex.ble...@gmail.com on 25 Nov 2010 at 7:22

GoogleCodeExporter commented 8 years ago
I was attempting to evaluate Mac ZFS for the first time, with 2 brand new 2TB 
Seagate drives and a dual bay sata->usb 2.0 docking station, connected to a 
MacBookPro.   I put both drives into a pool, but after a short while (without 
even copying anything to the ZFS partition!) it halted my system.
I rebooted, but no more than 30 minutes had passed, when this happened again.
After that, I unplugged the ZFS disk before rebooting.
I've noticed that many times external USB drives have "hickups", where the 
system doesn't see them for a second or two... not a big problem with Mac file 
system, but it looks like it would be deadly (and lose me any work I had in 
progress) if I have any ZFS drives connected to my system.

Original comment by Scott.Pa...@gmail.com on 15 Feb 2011 at 10:52

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
See also http://code.google.com/p/maczfs/wiki/USB

Original comment by alex.ble...@gmail.com on 16 Feb 2011 at 9:04

GoogleCodeExporter commented 8 years ago
Changing title to reflect USB issues.

Original comment by alex.ble...@gmail.com on 7 Mar 2012 at 11:54

GoogleCodeExporter commented 8 years ago
Issue 95 has been merged into this issue.

Original comment by alex.ble...@gmail.com on 7 Mar 2012 at 11:54

GoogleCodeExporter commented 8 years ago
I've similar issue (issue 123).
The crash happens all the time when restoring my laptop from sleep time and I'm 
simply re-connecting the HDD.

Original comment by ken...@gmail.com on 25 Nov 2013 at 9:40

GoogleCodeExporter commented 8 years ago
Another crash, twice in a row when tried to clone the repo from the Terminal:
git clone git@github.com:metabrainz/musicbrainz-server.git
on HDD via USB
My HDD is: WD My Passport 1TB USB 1000GB (Model: WDBBEP0010BBK).

Original comment by ken...@gmail.com on 25 Nov 2013 at 4:44

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
When cloned this repo on the other HDD (HFS):
git clone git@github.com:metabrainz/musicbrainz-server.git
it worked, but when moving this dir, it generated the crash again.

Original comment by ken...@gmail.com on 25 Nov 2013 at 4:54