と、 前回までNTFSについてあれこれ書いてきた。S.M.A.R.T.情報の診断結果を見ると不良セクタは特に問題がないが、使用時間が4.1年以上経っており、通信エラー数が多いとの結果が出ていた。HDDを増設するのに合わせて、NTFSのHDDをLinuxネイティブなファイルシステムにフォーマットしなおして使うことにした。
Linuxネイティブのファイルシステムにする理由
NTFSからLinuxネイティブのファイルシステムにする理由としては、以下のとおり。
- NTFSを安全に修復するには、Windowsの
chkdskが必要だが、Linuxには軽微な修正しか出来ないntfsfixしかない。 - 権限情報で、Steamライブラリや実行ファイルの権限問題が起きることがある
- 長期間・大容量のデータを読み書きするなら、HDDの断片化の起きにくいLinuxカーネルと親和性のあるファイルシステムの方が有利
ファイルシステムはどれにする
ではLinuxネイティブのファイルシステムのどれにするか?外付けHDDとは別にバックアップサーバーもあって、そちらではxfsにしていたのだけど、今回はext4にした。
理由としては、以下のとおり。
ext4はコピーオンライト(CoW)ファイルシステムと異なり、データ書き換え時に広範囲な空き領域を探す必要がないため、ランダム書き込みに弱いSMR(瓦磁気記録方式)ドライブでパフォーマンスの極端な低下を抑えやすいため。xfsはパーティション縮小ができない。
マウント設定は以下のとおり。ntfs3と比べてスッキリしている。最後の2はOS起動時にディスクにエラーの兆候があれば修復チェックを行うというもの。
UUID=f0d0de50-c639-4cca-a660-7f25e94980b7 /mnt/hdd_C ext4 defaults,nofail 0 2
変更後、sudo systemctl daemon-reloadをして最新の/etc/fstabを読み込ませる。
コピー手順
ロジテックHDDケース RAID対応 3.5インチ 2台にHDD A, Bの2台が格納されている。
- 新しく買ったHDD C1にHDD Bからコピーする。
- HDD Bをフォーマットする。
- HDD AからHDD Bにコピーする計画。
最初にsudo chown -R $USER:$USER /mnt/hdd2でユーザ権限にしておく。そして、同期コマンドはrsync -avhP --log-file=/home/arimasou16/Documents/rsync.log "/mnt/hdd_B/" "/mnt/hdd_C/"
コピーしてみると、途中で止まった…
コピー開始して、寝て次の日起きると、2026/04/04 00:00:26 [11091] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(716) [sender=3.2.7] で途中で止まっていた。
止まった原因を探るべくsudo journalctl --since "2026-04-03 23:55:00" --until "2026-04-04 00:05:00" | grep -iE "suspend|sleep|systemd-logind|rsync"でログ調査すると以下のとおりだった。
4月 04 00:00:25 pop-os cosmic-greeter[3789]: logind prepare to sleep missing data
4月 04 00:00:26 pop-os cosmic-session[2849]: sleeping for 2ms before restarting process cosmic-bg (restart 0)
4月 04 00:00:26 pop-os cosmic-session[2849]: sleeping for 5ms before restarting process cosmic-notifications (restart 0)
4月 04 00:00:26 pop-os cosmic-session[2849]: sleeping for 3ms before restarting process cosmic-panel (restart 0)
4月 04 00:00:26 pop-os cosmic-session[2849]: sleeping for 7ms before restarting process cosmic-comp (restart 0)
4月 04 00:00:26 pop-os cosmic-session[2849]: sleeping for 8ms before restarting process cosmic-files-applet (restart 0)
4月 04 00:00:26 pop-os cosmic-session[2849]: sleeping for 2ms before restarting process cosmic-launcher (restart 0)
4月 04 00:00:26 pop-os cosmic-session[2849]: sleeping for 8ms before restarting process cosmic-app-library (restart 0)
4月 04 00:00:26 pop-os cosmic-session[2849]: sleeping for 0ms before restarting process cosmic-workspaces (restart 0)
4月 04 00:00:53 pop-os cosmic-session[2849]: sleeping for 0ms before restarting process cosmic-comp (restart 0)
Pop!_OSのCOSMICデスクトップがクラッシュして、画面(GUI)のセッションだけが再起動したことが原因らしい。今までそんなこと一度も起きなかったのに…Geminiに聞くとtmuxをインストールして、その上でrsyncすればデスクトップがクラッシュしても止まらず、更にtmux attachすればセッションに再接続できるらしい2。
接続構成の確認
転送速度が遅いので、USB 3.0ポートか確認する。
転送速度は18MB/s。これだと数日かかる計算だ。lsusb -tでUSB情報をツリー表示したとき、Driver=uas, 5000Mなど480Mより大きい速度で表示されていればUSB 3.0となる。Driver=xhci_hcd/2p, 10000Mなんかは3.2 Gen2ポートを示している。
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 480M
・・・省略・・・
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 003: Dev 004, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 002: Dev 004, If 0, Class=Mass Storage, Driver=uas, 5000M
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 002: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 480M
|__ Port 002: Dev 002, If 1, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 002: Dev 002, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 002: Dev 002, If 3, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 003: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 003: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
そして、Class=Mass Storageとなっていれば外付けストレージということになる。更にUSBハブ経由で2台のHDDが1本のUSBポートを共有している構成になる。この場合、USB 3.0であっても、一車線道路の交互通行のような状態になり、速度が落ちてしまう。
これだったら、無線ではあるが、LAN内の別PCに外付けしてコピーした方が速い。 玄人志向 外付け 3.5型 SATA HDD/SSD ケース GW3.5AM-SU3G2Pが来るまで、別PCに外付けしたHDDと無線で同期することにした。
rsync -avhP --log-file=/home/arimasou16/Downloads/rsync.log -e "ssh -F /home/arimasou16/.ssh/config" /mnt/hdd_B/ server:/mnt/hdd_C/で再継続する。
リモート間でもそんなコマンドは変わらない。ssh設定ファイルの指定は--rsh="ssh...と思ったら、今は-e "ssh..."で良い。また標準パス~/.ssh/configであれば省略しても良いらしい。
速度は51M/sと少なくとも2倍以上には向上した。
複数、外部ストレージとの接続がある場合、どっちもUSB 3.0であるか確認する
そして、玄人志向外付けHDDケースが到着したので、こちらのUSB規格も確認する。lsblk -o NAME,SIZE,MOUNTPOINTS,MODELでドライブ名の確認をする。
NAME SIZE MOUNTPOINTS
MODEL
sda 10.9T /mnt/hdd2 WDC WD120EFGX-68CPHN0
sdb 7.3T ST8000DM004-2CX188
└─sdb1 7.3T /mnt/hdd1
sdc 3.6T ST4000DM000-1F2168
├─sdc1 16M
└─sdc2 3.6T
sr0 1024M BD-RW BDR-209M
zram0 16G [SWAP]
nvme0n1 476.9G KINGSTON OM8SEP4512N-A0
├─nvme0n1p1 1022M /boot/efi
├─nvme0n1p2 4G /recovery
├─nvme0n1p3 467.9G /
└─nvme0n1p4 4G
└─cryptswap 4G
そして、udevadm info -n /dev/sda | grep -E "ID_USB_DRIVER|ID_USB_SPEED"でデバイスの詳細情報からUSBドライバー名、接続速度をフィルターして表示する。
結果、E: ID_USB_DRIVER=usb-storageとE: ID_USB_DRIVER=uasという表示だった。lsusb -tのDriver=usb-storageなどと一致するから、それで判断できる。
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
|__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=uas, 10000M
玄人志向外付けHDDケースはuas, 10000Mと分かる。UASP(USB Attached SCSI Protocol)なのでより高速な転送速度が出ることが期待される。ということで、LAN内の同期を止めて、玄人志向外付けHDDとロジテックHDDケースで同期するようした。
USBコントローラーのパニック
300M/sと凄まじいまでに転送速度が向上したが、数時間後に3.24M 13% 1015.38kB/s 0:00:19と止まってしまう…
[ 6604.510239] sd 1:0:0:1: [sdb] tag#11 CDB: Write(16) 8a 00 00 00 00 02 98 b4 f4 22 00 00 04 00 00 00
[ 6604.510343] sd 1:0:0:1: [sdb] tag#10 uas_eh_abort_handler 0 uas-tag 16 inflight: CMD OUT
・・・省略・・・
[ 6604.511110] sd 1:0:0:1: [sdb] tag#0 CDB: Write(16) 8a 00 00 00 00 02 98 b4 dc 22 00 00 04 00 00 00
[ 6609.404356] [UFW BLOCK] IN=wlo1 OUT= MAC= SRC=fe80:0000:0000:0000:100b:b91e:422c:d22d DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=531 TC=0 HOPLIMIT=1 FLOWLBL=549256 PROTO=UDP SPT=60156 DPT=21027 LEN=491
sudo dmesg | tail -n 20で確認すると、不良セクタによる読み込み側による停止ではなく、書き込み側のエラーと分かった。uasドライバは速いが、大容量データを転送し続けると、USBケースの通信チップが処理しきれずにフリーズする相性問題3を抱えているらしい。
一旦こうなるとsudo umountしても駄目。なので、ケースの電源をオフ。そしてケース外して、暫くしてから再接続して電源入れ直しても駄目。何もしてないのにマウントすら出来ない状態。
[ 1928.252940] sd 2:0:0:1: [sdc] tag#21 CDB: Write(16) 8a 00 00 00 00 02 7c 80 00 22 00 00 00 88 00 00
[ 1928.273930] scsi host2: uas_eh_device_reset_handler start
前回、異常終了してDirtyフラグが立っているためにマウントのタイミングでジャーナル・リカバリ(自動修復)をしようと修復通信にすらUSBチップが耐えきれなくて再度フリーズしてしまう…こうなると、もうこのケースに入れてのマウントは出来ないので、再度、別PCのHDDに接続してLAN内による無線同期に戻した。
BOT(Bulk-Only Transport)通信に固定する
ケースがLinux対応でなかったからか?と思ったが、Linux対応と謳っていても大容量のデータ高速通信でテストしているわけではない。有名メーカーの外付けケースならばuas通信テストもクリアしているチップが搭載されているらしい。
とはいってもTerraMaster D4-320といった製品であってもLinuxとの接続・相性は難しい4。一説には、やはりntfs3からext4にしたことで、Linuxにおいては性能が引き上げらてしまったがために起きた悲劇とも言えるかも知れない。
Windows/Macはコンシューマー向けなので多少のUSBチップのエラーは目を瞑って動作するが、Linuxは厳格に処理される。そもそもサーバーの世界ではUSB接続は使わない。かつては、SATAで外付けできるeSATA(External SATA:外付けSATA)という規格があったが、家庭では流行らず絶滅。そして、サーバーや業務向けのDAS(Direct Attached Storage)といった外付けストレージでは、USBではなくSAS(Serial Attached SCSI)などの専用ケーブルを使った接続が主流となる。
ただ、ThunderboltはUSBプロトコルとは別のThunderboltプロトコルがType-C端子に同居していて、マザーボードPCIeという内部バスを、そのままケーブルの中に通して外に引っ張りだすPCIeトンネリングで通信する。ただ、ケースとPC側の両方がThunderbolt対応してなければならず、ケースも非常に業務用と高いものしかない。
ということでUASP無効化して、BOT通信に固定する。
まず、lsusbでUSBデバイス情報を表示する。ツリー表示のオプション-tは付けない場合、ベンダーID、プロダクトID、メーカー名、製品名が表示される。
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 004: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
・・・中略・・・
Bus 002 Device 004: ID 0789:0253 Logitec Corp. LHR USB Device
・・・後略・・・
そして、lsusb -tでツリー表示すればDriver=uasとUASPドライバが使われていることが分かる。なので、IDは0789:0253と分かる。
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 003: Dev 003, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 002: Dev 004, If 0, Class=Mass Storage, Driver=uas, 5000M
UAS無効化ルールをecho "options usb-storage quirks=0789:0253:u" | sudo tee /etc/modprobe.d/disable-uas.confとして書き込む。
そして、sudo update-initramfs -uとシステムの起動イメージに設定する。そして、sudo rebootしてPCを再起動する。
再起動後、lsusb -tして、|__ Port 002: Dev 004, If 0, Class=Mass Storage, Driver=usb-storage, 5000MとDriver=usb-storageとなっていればOK。
これで、外付けHDDとの接続・通信も安定するはずだ。
と、すったもんだのすえ、HDDをLinuxネイティブのファイルシステムへのフォーマット、同期など3日間ぐらいの作業の末、完了した。めでたし、めでたし。
-
途中までその通りやっていたが、その後起きなかったので、結局
ptyxisやcosmic terminalで作業して、そのようなチャンスは訪れなかった。 ↩︎ -
ケースは違うが、JMicron系チップなどで USB enclosures and Linux – Nelson’s log, Re: [PATCH v2] USB: uas: Add the no-UAS quirk for JMicron JMS561U — Linux Stable Kernel Updatesなどの報告がある。 ↩︎
-
[Help] D4-320 Failing To Register Drive on Linux - TerraMaster Forum ↩︎