linux:disk
ディスク関連
特定のディストリでないと動かないのあるかも
ディスク一覧
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 86.6M 1 loop /snap/core/4486 loop1 7:1 0 86.9M 1 loop /snap/core/4917 sda 8:0 0 10G 0 disk ├─sda1 8:1 0 1M 0 part └─sda2 8:2 0 10G 0 part / sr0 11:0 1 1024M 0 rom
IOスケジューラ
$ cat /sys/block/sda/queue/scheduler noop deadline [cfq]
Red Hat Enterprise Linux 7 Performance Tuning Guide 5.1.2. I/O Schedulers
- noop - 何もせずに受付順に処理。SSD等の高速ストレージや、別途スケジューラを持っているraidコントローラがある場合など
- deadline - 待ち時間を一定にするようにがんばる。データベースやSSD向け。SSDで大きなファイルを扱う場合はこちらが良いらしい?
- cfq - プロセス毎にキューを持つ。だいたいの環境で上手く動く
- anticipatory - ハードディスク向け、もはや使う事はないので忘れましょう(RHELでは既に無効化されてるっぽい)
Linux 5ではからシングルキューのIOスケジューラが削除され、マルチキュー対応のスケジューラのみとなっている。
- none - マルチキューのnoop、nvme接続のSSDのような非常に高速なデバイス向け
- bfq - HDD
- mq-deadline - マルチキューのdeadline、SSD
- kyber - SSD
ディスクの使用状況を調べる
$ df -h
メンテ
ファイルシステムの整合性をチェック
# fsck /dev/sda1
不良セクタの検出
# badblocks -sv -o bad.sda1.txt /dev/sda1
不良セクタが見つかったら、-o で指定したファイルに吐かれる。fsckで登録してそのブロックを使わないようにする
# fsck -l bad.sda1.txt /dev/sda1 # fsck -L bad.sda1.txt /dev/sda1
badblocksは時間がかかる。巨大なパーティションではちと辛い
UUIDを調べる(/etc/fstabで指定するUUID)
# blkid /dev/sdb1
ファイルシステム上は余裕があるのにdfではディスクが一杯
ファイルシステム上ではディスク容量に余裕があるのに、dfで見るとディスクが圧迫されている場合、解放漏れのfile descriptorが残っている可能性がある。これはrmされてファイルシステムから消えたがプログラム側でcloseされてないのでディスクが解放されてないために発生する
lsofコマンドで deleted という文字列が含まれているものを検索すると、ファイルをつかんでいるプロセスを見つけられる。
$ lsof | grep deleted
問題になるのは多くの場合ログファイル。プロセスを再起動することで解放できる。
linux/disk.txt · 最終更新: 2019/08/16 07:08 by nullpon