/dev/sda disappears, then suddenly reappears as /dev/sdb


7 posts
by anotherdude » Sat Dec 28, 2013 12:01 am
Code: Select all
Dec 27 21:34:21 babulina kernel: [155411.269403] usb 1-1.3: reset high-speed USB device number 4 using dwc_otg
Dec 27 21:34:27 babulina kernel: [155416.550330] sd 0:0:0:0: Device offlined - not ready after error recovery
Dec 27 21:34:27 babulina kernel: [155416.550523] sd 0:0:0:0: [sda] Unhandled error code
Dec 27 21:34:27 babulina kernel: [155416.550547] sd 0:0:0:0: [sda] 
Dec 27 21:34:27 babulina kernel: [155416.550561] Result: hostbyte=0x05 driverbyte=0x00
Dec 27 21:34:27 babulina kernel: [155416.550577] sd 0:0:0:0: [sda] CDB:
Dec 27 21:34:27 babulina kernel: [155416.550590] cdb[0]=0x2a: 2a 00 02 f3 53 31 00 00 1e 00
Dec 27 21:34:27 babulina kernel: [155416.550704] EXT4-fs warning (device sda1): ext4_end_bio:286: I/O error writing to inode 57754946 (offset 19075072 size 4096 starting block 49500978)
... and then a pile more EXT4-fs warnings nearly identical to the above, and then ...
Dec 27 21:34:27 babulina kernel: [155416.552026] sd 0:0:0:0: [sda] killing request
Dec 27 21:34:27 babulina kernel: [155416.552133] EXT4-fs warning (device sda1): ext4_end_bio:286: I/O error writing to inode 57754946 (offset 19320832 size 4096 starting block 49501038)
... and then a pile more EXT4-fs warnings nearly identical to the above, and then ...
Dec 27 21:34:27 babulina kernel: [155416.563816] sd 0:0:0:0: [sda] Unhandled error code
Dec 27 21:34:27 babulina kernel: [155416.563842] sd 0:0:0:0: [sda] 
Dec 27 21:34:27 babulina kernel: [155416.563898] Result: hostbyte=0x01 driverbyte=0x00
Dec 27 21:34:27 babulina kernel: [155416.563919] sd 0:0:0:0: [sda] CDB:
Dec 27 21:34:27 babulina kernel: [155416.563932] cdb[0]=0x2a: 2a 00 02 f3 53 4f 00 00 1e 00
Dec 27 21:34:27 babulina kernel: [155416.564097] EXT4-fs warning (device sda1): ext4_end_bio:286: I/O error writing to inode 57754946 (offset 19197952 size 4096 starting block 49501008)
... and then a pile more EXT4-fs warnings nearly identical to the above, and then ...
Dec 27 21:34:27 babulina kernel: [155416.580647] usb 1-1.3: USB disconnect, device number 4
Dec 27 21:34:35 babulina kernel: [155424.849516] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
Dec 27 21:34:35 babulina kernel: [155424.951095] usb 1-1.3: New USB device found, idVendor=152d, idProduct=2338
Dec 27 21:34:35 babulina kernel: [155424.951134] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Dec 27 21:34:35 babulina kernel: [155424.951154] usb 1-1.3: Product: USB to ATA/ATAPI bridge
Dec 27 21:34:35 babulina kernel: [155424.951170] usb 1-1.3: Manufacturer: JMicron
Dec 27 21:34:35 babulina kernel: [155424.951186] usb 1-1.3: SerialNumber: 000001D91CC4
Dec 27 21:34:35 babulina kernel: [155424.955597] usb-storage 1-1.3:1.0: USB Mass Storage device detected
Dec 27 21:34:35 babulina kernel: [155424.960691] scsi1 : usb-storage 1-1.3:1.0
Dec 27 21:34:36 babulina kernel: [155426.030335] scsi 1:0:0:0: Direct-Access     WDC WD10 EZRX-00L4HB0          PQ: 0 ANSI: 2 CCS
Dec 27 21:34:36 babulina kernel: [155426.033961] sd 1:0:0:0: [sdb] 244190646 4096-byte logical blocks: (1.00 TB/931 GiB)
Dec 27 21:34:36 babulina kernel: [155426.034964] sd 1:0:0:0: [sdb] Write Protect is off
Dec 27 21:34:36 babulina kernel: [155426.037338] sd 1:0:0:0: [sdb] 244190646 4096-byte logical blocks: (1.00 TB/931 GiB)
Dec 27 21:34:36 babulina kernel: [155426.061677]  sdb: sdb1
Dec 27 21:34:36 babulina kernel: [155426.063996] sd 1:0:0:0: [sdb] 244190646 4096-byte logical blocks: (1.00 TB/931 GiB)
Dec 27 21:34:36 babulina kernel: [155426.065877] sd 1:0:0:0: [sdb] Attached SCSI disk
Dec 27 21:34:39 babulina kernel: [155428.655621] EXT4-fs warning (device sda1): __ext4_read_dirblock:681: error reading directory block (ino 57753877, block 0)
... and then a pile more EXT4-fs warnings nearly identical to the above, and then ...
Dec 27 23:51:30 babulina kernel: [163639.894543] EXT4-fs (sdb1): recovery complete
Dec 27 23:51:30 babulina kernel: [163639.895377] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)


So, basically, the drive is alive and happy at /dev/sda, and then, all of a sudden, there's a USB reset, the drive disappears, and everything above it in the stack errors out. A while later, the drive reappears as /dev/sdb.

The drive is connected via a SATA to USB controller directly to the Raspberry Pi. It is powered by its own power supply (brick connected to the wallsocket).

I have disconnected the drive from the Raspberry Pi and connected it instead to my laptop, which is i386. I used the same SATA to USB controller. I resumed the transfers which had caused the drive to randomly get kicked out on the Raspberry Pi, and at a higher rate, because now the transfers were not occurring across the network from my laptop to the Raspberry Pi, but locally, from the laptop's HDD to the external HDD. Such interruptions did not occur while it was connected to the laptop.

So, I'm inclined to dismiss the idea that the disconnections are caused by an inadequate power supply or by an overheating SATA to USB controller.

Before setting up the Raspberry Pi I had the drive hooked up to a Nokia N810 using the same SATA to USB controller. While connected to the N810, it was also getting periodically kicked out, only to reappear a short while later. I had assumed that it was a bug in the drivers, because the N810 had a really old kernel. So, I was unpleasantly surprised to run into the same problem on my Raspberry Pi, which has kernel 3.10.24+.

In fact, the drive I have is actually a brand-new replacement for an old drive which had finally kicked the bucket after ten long years of service. However, not before I had hooked up that drive to the same SATA to USB controller to my N810. Guess what? It too was experiencing the same interruptions as this brand-new drive.

So, is this USB-mass-storage-device-getting-kicked-out an ARM thing? Is there something I can specify on the kernel command line to stop this from happening?

I read at https://bbs.archlinux.org/viewtopic.php?pid=873071 that it might be worth turning off autosuspend in usbcore, but the Raspberry Pi has no such setting under /sys/module/usbcore/parameters/autosuspend ...
Posts: 5
Joined: Fri Dec 27, 2013 9:46 pm
by default_user8 » Sat Dec 28, 2013 11:31 pm
Is the drive listed in the fstab file?
The answer is 42
User avatar
Posts: 176
Joined: Mon Nov 18, 2013 3:11 am
Location: Louisiana
by anotherdude » Sun Dec 29, 2013 12:42 am
Well, I intended to mount /dev/sda1 at boot, so I listed it in the fstab file, but since it keeps jumping between /dev/sda and /dev/sdb I have to keep updating the entry :( Here's the original listing:

Code: Select all
/dev/sda1       /mnt/babulina   ext3    defaults,noexec     0       3
Posts: 5
Joined: Fri Dec 27, 2013 9:46 pm
by DougieLawson » Sun Dec 29, 2013 2:57 am
Get the UUID of the device (sudo blkid). Use that in /etc/fstab and it won't matter if the device appears as /dev/sda or /dev/sdq it will get mounted where you want it mounted.

The other thing to look at is whether you can disable the power saving feature, that appears to cause the device to disconnect when you would least want it to disconnect.
Hacker on ZX80 and Microtan65
Unemployed mainframe database specialist.
Linux hacker since 1995.
RPi owner since 2012.
Twitter: @DougieLawson

Gaffer tape is "The Force", it has a dark side and a light side and it holds the Universe together.
User avatar
Posts: 5502
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
by default_user8 » Sun Dec 29, 2013 5:16 am
I recently ran into an issue with a new usb drive on my raspi nas setup similar to what you have. One of my drives died after 3 days of use so i sent it back to seagate and they replaced it. When i got the new drive and put it to use it changed to /dev/sda after a reboot and my primary drive was no longer accessible. I bought 2 different drives on purpose to test reliability, my main drive is a 1TB WD 7200rpm drive and my secondary drive( that is there for redundancy via rsync) is the Seagate 1TB 5400 drive. In my haste to get my nas back in order I didn’t format the new drive when it came in. I think that the drive management software preinstalled on the drive is what caused my problems. Once I formatted the new drive everything worked the way I had intended it to work.
The answer is 42
User avatar
Posts: 176
Joined: Mon Nov 18, 2013 3:11 am
Location: Louisiana
by anotherdude » Mon Dec 30, 2013 12:49 am
@DougieLawson doing the UUID thing is not a bad idea, but unfortunately I think it is insufficient. The problem is that the old block device stays mounted even though it's now non-existent. So, I would not only have to modify the fstab file, but I would have to detect when the drive gets kicked out, and I would have to unmount the mount point, then re-mount the mount point, and all my in-progress transfers would still fail.

I'll still read up on specifying UUID instead of block device and use that, if only to make the process of restoring the mount point as simple as umount <mountpoint> && mount <mountpoint>.

As for the power saving settings, could you please elaborate? Did you mean hdparm, or something else?

Thanks a lot for your insight!
Posts: 5
Joined: Fri Dec 27, 2013 9:46 pm
by anotherdude » Mon Dec 30, 2013 12:53 am
Actually, I guess I don't really need to umount if the block device is different, however, I'd rather avoid having the same mount point multiply mounted.
Posts: 5
Joined: Fri Dec 27, 2013 9:46 pm