Re: BTRFS doesn't handle USB device disconnect
On Wed, Dec 11, 2013 at 11:03:09AM -0500, Alan Stern wrote: > On Tue, 10 Dec 2013, Sarah Sharp wrote: > > On 3.13-rc1, the btrfs partion from the disconnected USB device > > continues to be listed as mounted. Yanking the cable produces some > > additional oops messages. It also produced a couple hard-hangs. > > Unfortunately, I didn't capture the dmesg during the hard-hangs, so I > > can't tell for sure which driver is to blame (uas, btrfs, or xhci). > > Does this happen with usb-storage instead of uas? > > What about with ehci-hcd instead of xhci-hcd? > > And just to be exotic, what about with dummy-hcd and the uas or > g_mass_storage gadget driver? I can't reproduce the hard-hangs (with xhci and uas), but I did manage to reproduce a bug in uas where the disconnect function hangs, and hangs the khubd thread as well. This happens even with the btrfs partition wiped from the drive, so it's not a btrfs issue. I'll send a separate bug report to Hans. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS doesn't handle USB device disconnect
On Wed, Dec 11, 2013 at 11:03:09AM -0500, Alan Stern wrote: > On Tue, 10 Dec 2013, Sarah Sharp wrote: > > > In order to stress test the uas driver (next-gen USB storage driver), I > > decided to run some tests with a USB 3.0 storage device with four 10GB > > partitions: BTRFS, ext3, ext4, and fat32. > > > > It seems that BTRFS doesn't handle unexpected USB disconnect very well. > > Is that expected behavior? It's something that's been known about for a while, but is clearly undesirable behaviour. I don't think anyone with the detailed knowledge of the FS code has investigated in enough depth to get to the point of proposing patches. I suspect it's just not shown up with enough disastrous consequences to bubble to the top of the stack of things to fix yet. I think we're still at the point of "you can use USB if you like, but don't be surprised if, sometimes, Bad Things happen when the bus disconnects briefly". The problems you show below do look quite like the kind of things we've seen btrfs doing on USB disconnects, so on only this evidence I wouldn't be quick to point any fingers at the USB layer (unless other filesystems corroborate the behaviour). Hugo. (I'm not a btrfs developer, but I do a reasonable amount of first-line support for it on IRC and linux-btrfs; we see these things every week or two). > > The BTRFS partition was created on an Ubuntu 13.10 system, with > > btrfs-tools version 0.19+20130705-1. > > > > On 3.12-rc6, if all partitions are mounted, and I yank the USB cable, > > the BTRFS filesystem still shows up as mounted. If I yank it multiple > > times, sometimes it's listed twice when the device is disconnected: > > > > /dev/sdb3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e4 type btrfs > > (rw,nosuid,nodev,uhelper=udisks2) > > /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e41 type btrfs > > (rw,nosuid,nodev,uhelper=udisks2) > > > > Sometimes (but not always) when I plug it back in, I can get /dev/sdc3 > > listed twice: > > > > /dev/sdb3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e4 type btrfs > > (rw,nosuid,nodev,uhelper=udisks2) > > /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e42 type btrfs > > (rw,nosuid,nodev,uhelper=udisks2) > > /dev/sdc1 on /media/sarah/ext3-part type ext3 > > (rw,nosuid,nodev,uhelper=udisks2) > > /dev/sdc2 on /media/sarah/ext4-part type ext4 > > (rw,nosuid,nodev,uhelper=udisks2) > > /dev/sdc4 on /media/sarah/fat32-part type vfat > > (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2) > > /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e41 type btrfs > > (rw,nosuid,nodev,uhelper=udisks2) > > On 3.13-rc1, the btrfs partion from the disconnected USB device > > continues to be listed as mounted. Yanking the cable produces some > > additional oops messages. It also produced a couple hard-hangs. > > Unfortunately, I didn't capture the dmesg during the hard-hangs, so I > > can't tell for sure which driver is to blame (uas, btrfs, or xhci). > > Does this happen with usb-storage instead of uas? > > What about with ehci-hcd instead of xhci-hcd? > > And just to be exotic, what about with dummy-hcd and the uas or > g_mass_storage gadget driver? -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- UNIX: British manufacturer of modular shelving units. --- signature.asc Description: Digital signature
Re: BTRFS doesn't handle USB device disconnect
On Tue, 10 Dec 2013, Sarah Sharp wrote: > In order to stress test the uas driver (next-gen USB storage driver), I > decided to run some tests with a USB 3.0 storage device with four 10GB > partitions: BTRFS, ext3, ext4, and fat32. > > It seems that BTRFS doesn't handle unexpected USB disconnect very well. > Is that expected behavior? > > The BTRFS partition was created on an Ubuntu 13.10 system, with > btrfs-tools version 0.19+20130705-1. > > On 3.12-rc6, if all partitions are mounted, and I yank the USB cable, > the BTRFS filesystem still shows up as mounted. If I yank it multiple > times, sometimes it's listed twice when the device is disconnected: > > /dev/sdb3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e4 type btrfs > (rw,nosuid,nodev,uhelper=udisks2) > /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e41 type btrfs > (rw,nosuid,nodev,uhelper=udisks2) > > Sometimes (but not always) when I plug it back in, I can get /dev/sdc3 > listed twice: > > /dev/sdb3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e4 type btrfs > (rw,nosuid,nodev,uhelper=udisks2) > /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e42 type btrfs > (rw,nosuid,nodev,uhelper=udisks2) > /dev/sdc1 on /media/sarah/ext3-part type ext3 > (rw,nosuid,nodev,uhelper=udisks2) > /dev/sdc2 on /media/sarah/ext4-part type ext4 > (rw,nosuid,nodev,uhelper=udisks2) > /dev/sdc4 on /media/sarah/fat32-part type vfat > (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2) > /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e41 type btrfs > (rw,nosuid,nodev,uhelper=udisks2) > > On 3.13-rc1, the btrfs partion from the disconnected USB device > continues to be listed as mounted. Yanking the cable produces some > additional oops messages. It also produced a couple hard-hangs. > Unfortunately, I didn't capture the dmesg during the hard-hangs, so I > can't tell for sure which driver is to blame (uas, btrfs, or xhci). Does this happen with usb-storage instead of uas? What about with ehci-hcd instead of xhci-hcd? And just to be exotic, what about with dummy-hcd and the uas or g_mass_storage gadget driver? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
