Depuis sa mise en service, le NAS sur Odroid XU4Q ne se comporte pas normalement:

• Mauvaises performances: accès disque lents (~10Mo/s)
• Les journaux indiquent des erreurs d'entrées/sorties

Jan 28 15:58:23 odroid kernel: print_req_error: I/O error, dev sda, sector 4337186864
Jan 28 15:58:23 odroid kernel: md/raid1:md0: sda1: rescheduling sector 4336920624
Jan 28 15:58:23 odroid kernel: md/raid1:md0: redirecting sector 4336920624 to other mirror: sdb1
Jan 28 15:58:23 odroid kernel: md/raid1:md0: sda1: rescheduling sector 4336920800
Jan 28 15:58:23 odroid kernel: md/raid1:md0: redirecting sector 4336920800 to other mirror: sdb1
Jan 28 15:58:23 odroid kernel: md/raid1:md0: sda1: rescheduling sector 4336986424
Jan 28 15:58:23 odroid kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
Jan 28 15:58:23 odroid kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x88 88 00 00 00 00 01 02 84 38 70 00 00 00 70 00 00
Jan 28 15:58:23 odroid kernel: print_req_error: I/O error, dev sda, sector 4337186928
Jan 28 15:58:23 odroid kernel: md/raid1:md0: redirecting sector 4336986424 to other mirror: sdb1
Jan 28 15:58:23 odroid kernel: md/raid1:md0: sda1: rescheduling sector 4336920688
Jan 28 15:58:23 odroid kernel: sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00
Jan 28 15:58:23 odroid kernel: md/raid1:md0: redirecting sector 4336920688 to other mirror: sdb1
Jan 28 15:58:24 odroid kernel: blk_partition_remap: fail for partition 1

Cependant les tests SMART sur le disque n'ont pas rapporté d'erreurs:

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%       102         -
# 2  Short offline       Completed without error       00%        51         -

pas d'erreurs voir désactivation du pilote UAS

Après redémarrage le volume RAID n'est pas correctement reconstruit, il est dans un état dégradé. Un des deux disques n'est pas utilisé. les logs indiquent:

Jun 08 18:29:09 odroid kernel: md: kicking non-fresh sda1 from array!
Jun 08 18:29:09 odroid kernel: md/raid1:md0: active with 1 out of 2 mirrors
Jun 08 18:29:09 odroid kernel: md0: detected capacity change from 0 to 4000649838592

cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sdb1[1]
      3906884608 blocks super 1.2 [2/1] [_U]
      bitmap: 3/30 pages [12KB], 65536KB chunk

Le superbloc est pourtant bien reconnu:

mdadm --examine /dev/sda1

Les informations détaillées du cluster md0

mdadm --detail /dev/md0

/dev/md0:
           Version : 1.2
     Creation Time : Thu May 21 11:23:47 2020
        Raid Level : raid1
        Array Size : 3906884608 (3725.90 GiB 4000.65 GB)
     Used Dev Size : 3906884608 (3725.90 GiB 4000.65 GB)
      Raid Devices : 2
     Total Devices : 1
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Mon Jun  8 18:29:11 2020
             State : clean, degraded 
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : odroid:0  (local to host odroid)
              UUID : 347185f5:3d61e963:83e024b8:a7ef05b0
            Events : 29975

    Number   Major   Minor   RaidDevice State
       -       0        0        0      removed
       1       8       17        1      active sync   /dev/sdb1

Ici es dernières lignes indiquent que l'un des périphériques a été retirer (removed).

La lecture du superbloc sur le

Cela peut se produire après une défaut d'alimentation. On peut re-introduire le disque:

mdadm /dev/md0 --re-add /dev/sda1

Après validation, le disque RAID est à nouvea

cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sda1[0] sdb1[1]
      3906884608 blocks super 1.2 [2/2] [UU]
      bitmap: 3/30 pages [12KB], 65536KB chunk
 
unused devices: <none>

Désactiver le groupe de volume

vgchange --activate n vgdata

Arrêter le volume RAID:

mdadm --stop /dev/md0

Les pilotes UAS peuvent mal réagir avec certaines puces USB3. vérifier s'il sont chargés

lsmod | grep uas
uas                    20480  0
usb_storage            49152  1 uas
scsi_mod              135168  4 sd_mod,usb_storage,uas,sg

C'est le cas ici, on determine l'ID des disques pour blacklister le pilote pour ces périphériques:

lsusb
Bus 006 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 004: ID 0480:b207 Toshiba America Inc
Bus 004 Device 005: ID 0480:b207 Toshiba America Inc
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ici les disques usb Toshiba ont pour ID 0480:b207.

echo "options usb-storage quirks=0480:b207:u" > /etc/modprobe.d/blacklist_uas_0480.conf
update-initramfs -u
reboot

Après redémarrage les logs doivent indiquer que le pilote UAS est blacklisté pour les périphériques

journalctl -k | grep -i quirks
Jan 28 15:58:19 odroid kernel: usb-storage 4-1.1:1.0: Quirks match for vid 0480 pid b207: 12000000

Dernières modifications:

options usb-storage quirks=0480:b207:tj

• https://unix.stackexchange.com/questions/239782/connection-problem-with-usb3-external-storage-on-linux-uas-driver-problem
• https://github.com/hardkernel/linux/commit/c18781b1ef56a800572e8342488504e4e818013a
• https://forum.odroid.com/viewtopic.php?t=17349