From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:52482 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750748AbcD1FJ1 (ORCPT ); Thu, 28 Apr 2016 01:09:27 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aveCb-0007tf-2P for linux-btrfs@vger.kernel.org; Thu, 28 Apr 2016 07:09:25 +0200 Received: from p50909051.dip0.t-ipconnect.de ([80.144.144.81]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Apr 2016 07:09:25 +0200 Received: from matthias by p50909051.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Apr 2016 07:09:25 +0200 To: linux-btrfs@vger.kernel.org From: Matthias Bodenbinder Subject: Re: Question: raid1 behaviour on failure Date: Thu, 28 Apr 2016 07:09:16 +0200 Message-ID: References: <57148B2E.6010904@cn.fujitsu.com> <571871FC.2010101@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: Am 26.04.2016 um 18:19 schrieb Henk Slager: > It looks like a JMS567 + SATA port multipliers behaind it are used in > this drivebay. The command lsusb -v could show that. So your HW > setup is like JBOD, not RAID. Here is the output of lsusb -v: Bus 003 Device 004: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x152d JMicron Technology Corp. / JMicron USA Technology Corp. idProduct 0x0567 bcdDevice 2.05 iManufacturer 10 JMicron iProduct 11 USB to ATA/ATAPI Bridge iSerial 5 152D00539000 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 44 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds Device Status: 0x0001 Self Powered > IMHO, using such a setup for software RAID (like btrfs RAID1) > fundamentally violates the concept of RAID (redundant array of > independent disks). It depends on where you define the system border > of the (independent) disks. > If it is at: > > A) the 4 (or 3 disk in this case) SATA+power interfaces inside the drivebay or > > B) inside the PC's chipset. > > In case A) there is a shared removable link (USB) inside the > filesystem processing machine. > In case B) the disks aren't really independent as they share a > removable link (and as proven by the (un)plug of 1 device affecting > all others). > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >