> [ ... ] when writes to a USB device fail due to a temporary > disconnection, the kernel can actually recognize that a write > error happened. [ ... ]
Usually, but who knows? Maybe half transfer gets written; maybe the data gets written to the wrong address; maybe stuff gets written but failure is reported, and this not just if the connection dies, but also if it does not. > are USB drives really that unreliable [ ... ] Welcome to the "real world", also called "Shenzen" :-). There aren't that many "USB drives", as I wrote somewhere there are usually USB host bus adapters (on the system side) and USB IO bus (usually SATA) bridges (on the device side). They both have to do difficult feats of conversion and signaling, and in the USB case they are usually designed by a stressed, overworked engineer in Guangzhou or Taiwan employed by a no-name contractor working who submitted the lowest bid to a no-name manufacturer, and was told to do the cheapest design to fabricate in the shortest possible time. Most of the time they mostly work, good enough for keyboard and mice, and for photos of cats on usb sticks; most users jut unplug and replug them in if they flake out. BTW my own USB keyboard and mice and their USB host bus adapter occasionaly crash too, and the cases where my webcam flakes out are more common than when it does not. USB is a mixed bag of poorly designed protocols and complex too, and it is very easy to do a bad implementation. There are similar SATA chips too (occasionally JMicron and Marvell for example are somewhat less awesome than they could be), and practically all Firewire bridge chips of old "lied" a lot except a few Oxford Semi ones (the legendary 911 series). I have even seen lying SAS "enterprise" grade storage interconnects. I had indeed previously written: > If you have concerns about the reliability of specific > storage and system configurations you should become or find a > system integration and qualification engineer who understand > the many subletities of storage devices and device-system > interconnects and who would run extensive tests on it; > storage and system commissioning is often far from trivial > even in seemingly simple cases, due in part to the enormous > complexity of interfaces, even when they have few bugs, and > test made with one combination often do not have the same > results even on apparently similar combinations. On the #Btrfs IRC channel there is a small group of cynical helpers, and when someone mentions "strange things happening" one of them usually immediately asks "USB?" and in most cases the answer is "how did you know?". That plus Btrfs is designed to work on top of a "well defined" block device abstraction that is assumed to "work correctly" (except for data corruption), and the Linux block device abstraction and SATA and USB layers beneath it are not designed to handle devices that "lie" (well, there are blacklists with workaround for known systematic bugs, but that is partial). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
