Windows版Storjノードで「hashstore compaction failed（EOF）」が毎日出る原因と直し方

StorjのWindowsノード運用で、ログに hashstore compaction failed や writing into compacted log: EOF が繰り返し出ると、「アップデートで直るはずでは？」と不安になります。実際、2026年2月のコミュニティでも、v1.147系を使っていても日次で発生するケースが報告されています。Storj Community Forum (official)
この記事では、このエラーが示す意味、起きやすい原因、そして“いま現場で効く”切り分けと復旧手順を、Windows前提でまとめます。

• Windows版Storjノードで「hashstore compaction failed（EOF）」が毎日出る原因と直し方
  • まず結論：EOFは「想定より短い＝ファイル断片化・切り詰め」系の軽度破損サイン
  • 症状の影響：すぐ致命傷とは限らないが、放置はおすすめしない
  • 典型原因（Windowsで起きやすい順）
  • すぐやるべき切り分けチェック（安全で効果が高い順）
    • 1) Windowsのディスク検査と修復（最優先）
    • 2) SMARTの確認（“軽度破損”が実は前兆のことも）
    • 3) Storjの修復系ツールを使う（write-hashtbl が候補）
    • 4) セキュリティソフト／バックアップ対象から除外
  • よくある誤解：「衛星が違うのに出る＝ネットワーク問題？」ではない
  • それでも直らない場合の現実的な方針
  • まとめ：アップデート待ちより「ディスク健全性→整合性再生成」が最短ルート

まず結論：EOFは「想定より短い＝ファイル断片化・切り詰め」系の軽度破損サイン

エラー本文に出る EOF（End Of File） は、開発側の見立てでも「期待した長さより手前でファイルが途切れている（truncated）」状況を強く示します。つまり“共有ロック競合”よりは、ログファイルの一部が欠けた／途中で切れた可能性が高い、という方向です。Storj Community Forum (official)

このとき compaction（圧縮・整理処理）が、古いログから新しい「compacted log」を作る途中でつまずき、同じ衛星・別衛星でも繰り返し出ることがあります。Storj Community Forum (official)

症状の影響：すぐ致命傷とは限らないが、放置はおすすめしない

• ログが毎日出るだけでノードが動き続けることもあります（次のcompactionで通る可能性がある、と示唆されています）。Storj Community Forum (official)

• ただし「一部ノードがcompactできない」という報告もあり、蓄積するとパフォーマンスや安定性に影響し得ます。Storj Community Forum (official)

• もしログが FATAL / Unrecoverable に寄ってきたら、早めに手当てした方が安全です（別スレでは“Unrecoverable error”かどうか確認が入っています）。Storj Community Forum (official)

典型原因（Windowsで起きやすい順）

1. ディスク／ファイルシステムの不整合（突然の再起動・電断・USB外付けの瞬断など）

2. 物理ディスク劣化（SMART上の代替処理増加、CRCエラー、再試行の増加など）

3. セキュリティソフトの介入（リアルタイムスキャンでI/Oが遅延・中断、バックアップソフトのスナップショット）

4. 空き容量不足・断片化・巨大ファイル運用（ログがGB級になりやすい環境）

5. バージョン差分由来の挙動変化（ログの検査や出力が増え、見える化されただけのケースも）

なお、v1.147.5の変更点にはhashstoreまわりの改善が複数含まれます（例：Windowsでのファイルオープン方式に関する変更など）。ただし“これでEOFが必ず消える”とまでは言えないため、まずはディスク健全性の確認が近道です。GitHub

すぐやるべき切り分けチェック（安全で効果が高い順）

1) Windowsのディスク検査と修復（最優先）

開発側からも「ディスク上のエラーをチェックして直してほしい」と明言されています。Storj Community Forum (official)
Windowsなら、まずは以下を実施します。

• イベントビューア：Disk / Ntfs の警告・エラーが出ていないか

• chkdsk（管理者権限）：対象ドライブの整合性チェック＋修復（必要なら再起動時に実行）

外付け・USBケース運用なら、ケーブル交換・別ポート・電源の見直しも同時にやると再発率が下がります。

2) SMARTの確認（“軽度破損”が実は前兆のことも）

EOF系は「たまたま」よりも「劣化の兆候」から始まることがあります。
SMARTで以下が増えている場合は、復旧より先に退避・交換計画を立てるのが安全です。

• Reallocated / Pending / Uncorrectable

• CRC Error（特にSATAケーブルやケース由来）

3) Storjの修復系ツールを使う（write-hashtbl が候補）

コミュニティの回答では、ディスク修復後に write-hashtblツールを使う案が挙げられています。Storj Community Forum (official)
これはhashstoreの整合性を取り直す方向の手当てで、compactionが通る状態に戻す狙いがあります。

ポイントは順番で、**「ディスクのエラー修復 → ツール実行」**が基本です。土台（ファイルシステム）が壊れている状態で上物を直しても再発しやすいからです。

4) セキュリティソフト／バックアップ対象から除外

Storjのデータディレクトリ（例：D:\hashstore\...）を、リアルタイムスキャンや世代バックアップの対象にしていると、I/Oが不安定になりやすいです。
除外設定は運用リスクもあるので、最低限「Storjデータディレクトリだけ」「署名済みアプリは許可」など、環境に合わせて調整してください。

よくある誤解：「衛星が違うのに出る＝ネットワーク問題？」ではない

ログには衛星IDが出ますが、今回の主眼は ローカルのhashstoreログ（ファイル）への書き込み／読み取りです。EOFはネットワーク切断というより、**“読もうとしたローカルファイルが途中で終わっていた”**という性質のエラーなので、まずはストレージ側を疑うのが合理的です。Storj Community Forum (official)

それでも直らない場合の現実的な方針

• 再発頻度が下がった：次回compactionで自然に収束する可能性（「次のcompactionが通るかも」との示唆あり）Storj Community Forum (official)

• 毎日出続ける／増える：ディスクの物理問題や、特定ファイルの破損が疑わしい。SMARTとイベントログを根拠に、移行・交換を優先

• Unrecoverable/FATALに近づく：影響が広がる前に、ログと環境情報を添えてコミュニティへ共有（開発側にエスカレーションされた経緯もあります）Storj Community Forum (official)

まとめ：アップデート待ちより「ディスク健全性→整合性再生成」が最短ルート

「hashstore compaction failed（EOF）」は、現象としては“新しい不具合”に見えても、実態は ローカルファイルの欠け・不整合で説明できることが多いタイプです。まずはWindowsのディスク検査とSMART確認で土台を固め、次にwrite-hashtbl等の整合性回復手段を当てる。これが、再発を止めるいちばん確度の高い流れです。Storj Community Forum (official)+1