USB drives I/O error during writes

Mark81 · 10. Juli 2019

I have two NAS based on OMV, one is an Atom SBC the other is a RPi3.
Both have a USB external hard-disk, with dedicated power supply.

Whenever I try to write a "large" file (say > 1 GB) I got a lot of I/O errors and the disks disconnect. Example on RPi3:

Code

[  487.411996] usb 1-1.2: USB disconnect, device number 6
[  487.417386] EXT4-fs warning (device sda1): ext4_end_bio:323: I/O error 10 writing to inode 2359299 (offset 58720256 size 2101248 starting block 49664)
[  487.417400] Buffer I/O error on device sda1, logical block 49152
[  487.417411] Buffer I/O error on device sda1, logical block 49153
[  487.417415] Buffer I/O error on device sda1, logical block 49154
[  487.417419] Buffer I/O error on device sda1, logical block 49155
[  487.417423] Buffer I/O error on device sda1, logical block 49156
[  487.417427] Buffer I/O error on device sda1, logical block 49157
[  487.417432] Buffer I/O error on device sda1, logical block 49158
[  487.417436] Buffer I/O error on device sda1, logical block 49159
[  487.417440] Buffer I/O error on device sda1, logical block 49160
[  487.417444] Buffer I/O error on device sda1, logical block 49161
[  487.419443] EXT4-fs warning (device sda1): ext4_end_bio:323: I/O error 10 writing to inode 2359299 (offset 58720256 size 4198400 starting block 49920)
[  487.419927] EXT4-fs warning (device sda1): ext4_end_bio:323: I/O error 10 writing to inode 2359299 (offset 58720256 size 4198400 starting block 50176)
[  487.421682] EXT4-fs warning (device sda1): ext4_end_bio:323: I/O error 10 writing to inode 2359299 (offset 58720256 size 6295552 starting block 50432)
[  487.422187] EXT4-fs warning (device sda1): ext4_end_bio:323: I/O error 10 writing to inode 2359299 (offset 58720256 size 6295552 starting block 50688)
[  487.423876] EXT4-fs warning (device sda1): ext4_end_bio:323: I/O error 10 writing to inode 2359299 (offset 58720256 size 8388608 starting block 50944)
[  487.424338] EXT4-fs warning (device sda1): ext4_end_bio:323: I/O error 10 writing to inode 2359299 (offset 58720256 size 8388608 starting block 51200)
[  487.426161] EXT4-fs warning (device sda1): ext4_end_bio:323: I/O error 10 writing to inode 2359299 (offset 58720256 size 8388608 starting block 51456)
[  487.427679] EXT4-fs warning (device sda1): ext4_end_bio:323: I/O error 10 writing to inode 2359299 (offset 67108864 size 3149824 starting block 51712)
[  487.428152] EXT4-fs warning (device sda1): ext4_end_bio:323: I/O error 10 writing to inode 2359299 (offset 67108864 size 3149824 starting block 51968)
[  487.503619] JBD2: Detected IO errors while flushing file data on sda1-8
[  487.503932] Aborting journal on device sda1-8.
[  487.503961] EXT4-fs (sda1): Delayed block allocation failed for inode 2359299 at logical offset 35152 with max blocks 640 with error 30
[  487.503994] JBD2: Error -5 detected when updating journal superblock for sda1-8.
[  487.508355] EXT4-fs (sda1): This should not happen!! Data will be lost


[  487.512962] EXT4-fs error (device sda1) in ext4_writepages:2907: Journal has aborted
[  487.515348] EXT4-fs (sda1): previous I/O error to superblock detected
[  487.516451] EXT4-fs (sda1): previous I/O error to superblock detected
[  487.516573] EXT4-fs error (device sda1): ext4_journal_check_start:61: Detected aborted journal
[  487.518940] EXT4-fs (sda1): Remounting filesystem read-only
[  487.521356] EXT4-fs (sda1): previous I/O error to superblock detected
[  495.390409] usb 1-1.2: new high-speed USB device number 7 using dwc_otg
[  495.521444] usb 1-1.2: New USB device found, idVendor=13fd, idProduct=0840
[  495.521457] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  495.521466] usb 1-1.2: Product: External
[  495.521474] usb 1-1.2: Manufacturer: Generic
[  495.521482] usb 1-1.2: SerialNumber: 533144354E53414639313631
[  495.522267] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[  495.525034] scsi host1: usb-storage 1-1.2:1.0
[  496.551133] scsi 1:0:0:0: Direct-Access     Generic  External         1.14 PQ: 0 ANSI: 4
[  496.552149] sd 1:0:0:0: Attached scsi generic sg0 type 0
[  496.552215] sd 1:0:0:0: [sdb] 234441647 512-byte logical blocks: (120 GB/112 GiB)
[  496.552621] sd 1:0:0:0: [sdb] Write Protect is off
[  496.552634] sd 1:0:0:0: [sdb] Mode Sense: 23 00 00 00
[  496.553106] sd 1:0:0:0: [sdb] No Caching mode page found
[  496.553124] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[  496.577478]  sdb: sdb1
[  496.578920] sd 1:0:0:0: [sdb] Attached SCSI disk
[  497.343918] EXT4-fs (sdb1): mounting with "discard" option, but the device does not support discard
[  497.343929] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,discard,acl

Alles anzeigen

On RPi3 the disk is remounted but on the other machine I have to cycle power the hard-disk and reconfigure the "Disk" section of OMV.
Because they are different platform, with different hard-disk and different USB controllers the only common thing is OMV.

It's not reliable with these problems. I must be able to write such a "large" files.
Please, would you help me to understand how to fix the problem?

Of course feel free to ask me any detail that might be useful.

crashtest · 11. Juli 2019

Zitat von Mark81

On RPi3 the disk is remounted but on the other machine I have to cycle power the hard-disk and reconfigure the "Disk" section of OMV.
Because they are different platform, with different hard-disk and different USB controllers the only common thing is OMV.

There are two things in common, in this case. "Debian" and "USB connected" hard drives. OMV (an application) doesn't have anything to do with physically interfacing hardware.
______________________________________________________________

Regarding the drive connected to the R-PI; have you looked at SMART data for /dev/sda1 ?

In this case, with EXT4-FS warnings, using fsck to scan the drive might be a good idea. fsck /dev/sda1 Unmount the drive before the scan. There's a list of exit codes here.

Zitat von Mark81

It's not reliable with these problems.

I noted you posted, last year, regarding an issue with a USB connected drive. If you're looking for reliability, you might consider using an adapter/enclosure with a good USB-to-SATA chip set. Better yet, platforms with native SATA ports eliminate USB-to-SATA issues.

Mark81 · 11. Juli 2019

Yep, in fact the problem is not solved since last year.
Because OMV is strictly tied to Debian are the same thing: I mean, I understand OMV is only the software layer, but because they choose Debian as o.s. I assume it should work for all OMV features. And USB/SATA adapters are not discouraged (at least, I didn't find any note about them).

The same hard-disks with the same USB/SATA adapter connected to a common Windows machine work fine also with very big files. So I don't think both have faulty SATA chipset.
Anyway, I will try to look at SMART data.

crashtest · 11. Juli 2019

Zitat von Mark81

USB/SATA adapters are not discouraged (at least, I didn't find any note about them).

There are differences between USB chip sets. Some are better than others, JMS578 and RTL8153 are a couple examples of good chip sets.

Jetzt mitmachen!