RaspberryPi4にUSB3.0でHDDを接続した際にはまった件

# はじめに
RaspberryPi4にUSB3.0でHDDを接続してNAS運用をする際に遭遇したトラブルのメモ

# システム構成
* RaspberryPi4(RAM:4GB/OS:bullseye/SSD-boot)
* HDD(3.5inch-1TB+Logitec HDD case(USB3.0))
* MacBook Air M1(クライアントマシン)

# 設定内容
* NAS用のsambaのインストール。MacのTimeMachine保存領域に使いたかったので、そのための設定も追加(この部分の詳細は割愛)
* fdisk /dev/sdb で/dev/sdb1を作成(全領域を割り当て)
* mkfs.ext4 /dev/sdb1 でext4ファイルシステムを構築
* mkdir /extdisk ; mount /dev/sdb1 /extdisk で作成したディレクトリにディスクをマウント
* /etc/samba/smb.confを編集して、/extdiskを外部に公開する設定を追加した後、sambaサービスを開始

```
pi@raspi-4b:~ $ sudo fdisk /dev/sdb                # /dev/sdb1を作成
pi@raspi-4b:~ $ sudo mkfs.ext4 /dev/sdb1           # ファイルシステムを作成
pi@raspi-4b:~ $ sudo mount /dev/sdb1 /extdisk      # ディスクをマウント
pi@raspi-4b:~ $ sudo systemctl start smb.service   # sambaを開始
```

# 発生したトラブル
Macで当該共有ディスクをTimeMachine保存先に設定して、フルバックアップを実行。差分バックアップが繰り返されると以下のようなエラーがRaspberryPi4のdmesgに出力された。

```
[ 2022.840268] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100485: comm smbd: corrupted xattr block 224403491
[ 2022.857107] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100485: comm smbd: corrupted xattr block 224403491
[ 3026.947811] EXT4-fs warning (device sdb1): ext4_dirblock_csum_verify:377: inode #16252929: comm smbd: No space for directory leaf checksum. Please run e2fsck -D.
[ 3026.947837] EXT4-fs error (device sdb1): __ext4_find_entry:1547: inode #16252929: comm smbd: checksumming directory block 0
[ 3026.964442] EXT4-fs warning (device sdb1): ext4_dirblock_csum_verify:377: inode #16252929: comm smbd: No space for directory leaf checksum. Please run e2fsck -D.
[ 3026.964466] EXT4-fs error (device sdb1): __ext4_find_entry:1547: inode #16252929: comm smbd: checksumming directory block 0
[ 4073.068013] EXT4-fs warning (device sdb1): ext4_dirblock_csum_verify:377: inode #16252929: comm smbd: No space for directory leaf checksum. Please run e2fsck -D.
[ 4073.068033] EXT4-fs error (device sdb1): __ext4_find_entry:1547: inode #16252929: comm smbd: checksumming directory block 0
[ 4073.092040] EXT4-fs warning (device sdb1): ext4_dirblock_csum_verify:377: inode #16252929: comm smbd: No space for directory leaf checksum. Please run e2fsck -D.
[ 4073.092060] EXT4-fs error (device sdb1): __ext4_find_entry:1547: inode #16252929: comm smbd: checksumming directory block 0
[ 4073.281768] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100504: comm smbd: corrupted xattr block 224403491
[ 4073.317069] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100504: comm smbd: corrupted xattr block 224403491
[ 4073.334214] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100504: comm smbd: corrupted xattr block 224403491
[ 4073.350330] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100504: comm smbd: corrupted xattr block 224403491
[ 4073.366856] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100504: comm smbd: corrupted xattr block 224403491
[ 4073.389492] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100504: comm smbd: corrupted xattr block 224403491
[ 4073.408522] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100504: comm smbd: corrupted xattr block 224403491
[ 4073.425726] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100504: comm smbd: corrupted xattr block 224403491
[ 4089.514959] EXT4-fs error: 180 callbacks suppressed
[ 4089.514966] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4089.543181] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4089.559852] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4089.576411] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4089.593039] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4089.619488] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4089.634792] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4089.651505] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4089.668032] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4089.684677] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4262.459607] EXT4-fs warning (device sdb1): ext4_dirblock_csum_verify:377: inode #16252929: comm smbd: No space for directory leaf checksum. Please run e2fsck -D.
[ 4262.459617] EXT4-fs error: 22 callbacks suppressed
[ 4262.459622] EXT4-fs error (device sdb1): __ext4_find_entry:1547: inode #16252929: comm smbd: checksumming directory block 0
[ 4262.493161] EXT4-fs warning (device sdb1): ext4_dirblock_csum_verify:377: inode #16252929: comm smbd: No space for directory leaf checksum. Please run e2fsck -D.
[ 4262.493173] EXT4-fs error (device sdb1): __ext4_find_entry:1547: inode #16252929: comm smbd: checksumming directory block 0
[ 4272.816057] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4272.839033] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4272.864005] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4272.888639] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4272.913591] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4272.947218] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4272.997094] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4273.030619] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4273.063597] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
[ 4273.088525] EXT4-fs error (device sdb1): ext4_xattr_block_get:536: inode #56100497: comm smbd: corrupted xattr block 224403491
```

今回使ったHDDが使い古しのものなので壊れているのか？とも思ったが、経験的にディスクが壊れている時のエラーとは違うように見える。が、念のため、以下の確認を実行。

```
pi@raspi-4b:~ $ sudo systemctl stop smb.service  # sambaを止める。止めないとdiskをアンマウントできない
pi@raspi-4b:~ $ sudo umount /extdisk             # ディスクをアンマウント
pi@raspi-4b:~ $ sudo smartctl -A -d sat /dev/sdb # smartctlでディスクの状態を確認
smartctl 7.2 2020-12-30 r5155 [armv7l-linux-5.10.103-v7l+] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   082   063   ---    Pre-fail  Always       -       197236923
  3 Spin_Up_Time            0x0003   095   094   ---    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   099   099   ---    Old_age   Always       -       1050
  5 Reallocated_Sector_Ct   0x0033   100   100   ---    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   086   060   ---    Pre-fail  Always       -       425312895
  9 Power_On_Hours          0x0032   068   068   ---    Old_age   Always       -       28606
 10 Spin_Retry_Count        0x0013   100   100   ---    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   ---    Old_age   Always       -       487
184 End-to-End_Error        0x0032   100   100   ---    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   ---    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   099   ---    Old_age   Always       -       8590065666
189 High_Fly_Writes         0x003a   100   100   ---    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   066   051   ---    Old_age   Always       -       34 (Min/Max 8/36)
191 G-Sense_Error_Rate      0x0032   100   100   ---    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   ---    Old_age   Always       -       64
193 Load_Cycle_Count        0x0032   087   087   ---    Old_age   Always       -       26408
194 Temperature_Celsius     0x0022   034   049   ---    Old_age   Always       -       34 (0 8 0 0 0)
195 Hardware_ECC_Recovered  0x001a   118   099   ---    Old_age   Always       -       197236923
197 Current_Pending_Sector  0x0012   100   100   ---    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   ---    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   ---    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   ---    Old_age   Offline      -       27101 (233 149 0)
241 Total_LBAs_Written      0x0000   100   253   ---    Old_age   Offline      -       4276778520
242 Total_LBAs_Read         0x0000   100   253   ---    Old_age   Offline      -       2794321819

pi@raspi-4b:~ $ sudo smartctl -l selftest -d sat /dev/sdb # smartctlでディスクテストを実行
smartctl 7.2 2020-12-30 r5155 [armv7l-linux-5.10.103-v7l+] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== 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  Short offline       Completed without error       00%         4         -
# 2  Extended offline    Completed without error       00%         4         -
# 3  Short offline       Completed without error       00%         1         -

pi@raspi-4b:~ $ sudo smartctl -l error -d sat /dev/sdb # smartctlでディスクのエラーを確認
smartctl 7.2 2020-12-30 r5155 [armv7l-linux-5.10.103-v7l+] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
No Errors Logged
```

HDD自体には問題がないようだった。これはどうしたものか…。とりあえず、以下を実行して、sambaのサービスを再開したところ、Macからは問題なくアクセスできている模様。

```
pi@raspi-4b:~ $sudo fsck.ext4 -D /dev/sdb1
pi@raspi-4b:~ $sudo fsck.ext4 -a /dev/sdb1
pi@raspi-4b:~ $sudo mount /dev/sdb1 /extdisk
pi@raspi-4b:~ $sudo systemctl start smbd.service
```

エラーなしで差分バックアップが取れることもあるので、エラーがでたらfsckで修復する、という方法で対応していたが、やっぱり釈然としない。使いながら対応方法を探すことにした。

# 対策1
[こちら](https://www.abten.net/2021/03/1816/)の情報によると、RaspberryPiはusb接続のSSDがドライバとの相性で不安定になることがあるらしい。こちらの情報を参考にして当該HDDのusbドライバをuasからusb-storageに切り替えてみたが、これは効果なし。

# 対策2
[こちら](https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/)の情報によると、RaspberryPiにSSD/HDDを接続する際に使うUSB-Apapterには相性があるようで、実績のあるデバイスがリストアップされていた。これを見る限り、今回使っているLogitecのものはリストに上がっていない。そう言えば、現在起動に使っているUSB接続のSSDでは何もエラーもなく快適に使えている。改めてUSB-Adapterについて確認してみた。

```
pi@raspi-4b:~ $ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
```

SSDの接続に使っているUSB-AdapterはASMediaのもののようだ。こちらは上のページのリストには載っていた。これを選んだのは単なる偶然(Amazonで安価だったので購入したもの)。やっぱり事前に調査して実績のあるものを使うべきだったのか…

# 対策3
ASM1153を使っているUSB-Adapterを購入した。Amazonでデバイス型番を指定して検索し、一番安価だったもの。安価な理由は、3.5インチHDDをつなぐ際におそらく絶対必要な12VのACアダプタが付属していないため。もちろん電源端子はついている。12VのACアダプタが手元にあったので個人的には困らなかったが、知らずに購入した人は慌てることになるので注意が必要かと。ただし、2.5インチHDDやSSDをつなぐ際は電源は不要ではないかと思う。HDDをLogitecのケースから取り出して、こちらのUSB-Adapterに接続してみる。以下のように正常に認識され、無事にマウントできた。

```
[96474.793154] usb 1-1.4: USB disconnect, device number 3
[96474.799809] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
[96474.801235] sd 1:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00
[96692.401600] usb 2-1: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[96692.432734] usb 2-1: New USB device found, idVendor=174c, idProduct=1153, bcdDevice= 1.00
[96692.432757] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[96692.432775] usb 2-1: Product: Ugreen Storage Device
[96692.432792] usb 2-1: Manufacturer: Ugreen
[96692.432809] usb 2-1: SerialNumber: 26A1EE831A43
[96692.479050] scsi host1: uas
[96692.481977] scsi 1:0:0:0: Direct-Access     ST1000NM 0011             0    PQ: 0 ANSI: 6
[96692.484239] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[96692.484428] sd 1:0:0:0: [sdb] Write Protect is off
[96692.484449] sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00
[96692.484794] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[96692.485525] sd 1:0:0:0: Attached scsi generic sg1 type 0
[96692.485687] sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes
[96692.593639]  sdb: sdb1
[96692.595901] sd 1:0:0:0: [sdb] Attached SCSI disk
[96940.562922] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
```

lsusbの結果はこちら。当然だが所望のデバイス(ASM1153)が正常に認識されている。

```
pi@raspi-4b:~ $ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 003: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```

# まとめ
その後、数日かけて10回ほどMacからRaspberryPi4にsamba経由でつないで当該ディスクに差分バックアップを取っているが、今のところ以前のようなエラーは発生していない。ハードの相性問題というオチで悲しい。おそらく問題は解消されたのだと思うが、もうしばらく様子を見ていく。

# 追記(2022/04/10)
この文書を書いてからこれまで、MacのTimeMachineの保存先として運用を続けながら様子を見ているが、上記のようなエラーは今のところ一度も発生していない。やはりRaspberryPi4とUSB-Apapterのハード的な相性がよくなかったことが原因だったようだ。LogitecのHDDケースはTVの録画用にでも転用しようと思う。