8
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Ubuntu を長時間待機させるとSSDにアクセスできなくなる

Last updated at Posted at 2020-06-24

解決方法がほぼ参照先のコピペみたいになったが,3日程悩んだので投稿する.

問題

あるSSD(今回は Transcend製SSD 256GB)では,一定時間操作がないとSSDにアクセスできなくなり,システムが停止する.

問題の起きた環境(抜粋)

  • Computer model : PRODESK 600 G5
  • OS : Ubuntu server 20.04 LTS
  • SSD model(入れ替えた) : TS256GMTE220S

具体的な症状

  • 日中はほとんど問題がない
  • システムを起動したまま翌日まで放っておくと SSH でログインができない
  • サーバにディスプレイを接続すると以下のエラーが大量に表示される
    • systemd-journald[484]: Failed to write entry (xx items, xxx bytes), ignoring: Read-only file system
    • EXT4-fs error (device nvme0n1p2): ext4_find_entry:1463: inode #xxxxx: comm systemd-udevd: reading directory iblock 0
  • サーバに直接キーボードを接続して Ctrl + Alt + Del キーを押してもシャットダウンできない

原因

  • APST(Autonomous Power State Transition)が特定の SSD に対してうまく動かないことがある

2021.4.5 追記

  • SSDを一度フォーマットし,OSを再インストールしたらこの問題が発生しなくなった.OSのインストール時に何らかのエラーが発生していた可能性がある
  • ここで使用したSSDは,OS稼働開始3ヶ月で読み書きのアクセスができなくなる不具合が発生した.もしかしたら何らかの初期不良を抱えていた可能性がある

対応方法

  • nvme のインストール

    $ sudo apt install nvme-cli
    
  • /etc/default/grub ファイルを編集

    $ sudo nano /etc/default/grub
    
  • "GRUB_CMDLINE_LINUX_DEFAULT" で始まる行の "" 内に "nvme_core.default_ps_max_latency_us=0" を追記し,上書き保存

    例:

    GRUB_CMDLINE_LINUX_DEFAULT="nvme_core.default_ps_max_latency_us=0"
    
  • GRUB2設定ファイルを更新

    $ sudo update-grub
    

所感

やはりサーバ機は正規のサーバ用マシンを使ったほうが安定するのだろうか.無闇にハードウェア構成をいじるとうまく行かないことがあるという勉強になった.

参考文献

8
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?