はじめに
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
こちらの情報によると、RaspberryPiはusb接続のSSDがドライバとの相性で不安定になることがあるらしい。こちらの情報を参考にして当該HDDのusbドライバをuasからusb-storageに切り替えてみたが、これは効果なし。
対策2
こちらの情報によると、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の録画用にでも転用しようと思う。