調子のいまいちなHDDをSSDに交換したところ、XFSのファイルシステムが簡単にはmountできなかった件。

By | 2020年12月16日 , Last update: 2021年2月11日
0 Comment

はじめに

前の記事でdynabookのSSDを換装した件について書きました。

取り外したSSDは、boot後にファイルシステムへのアクセスが始まると「ブーン」という異音を発していた2TBのHDDと交換することにしました。

この作業が一筋縄では行かなかったので、作業の経過についてメモすることにしました。

なお、2TBのHDDはLinuxのファイルサーバ用として使用していますので、何の前触れもなくLinux関連の用語が登場しますが、その点についてはあしからずご了承願います。

スポンサーリンク

事前作業

ファイルの退避

当該のHDDはWD(Western Digital)のHDDで、同一シリーズで別ロットの2TBのHDDとともに外付けのUSBのHDDケースに入れて使っています↓

HDDケースをテーブルの上に置いてみると↓のような感じになります。

交換前の中身はこんな感じです。

正直なところ、どちらが異音を発するものであったかの記憶が曖昧になりかけていましたが、「/dev/hdcとして認識されている方が異音を発しているのだろう。」と見当をつけてから、rsyncコマンドで別のファイルサーバにファイルを退避させました。

rsyncコマンドによる退避作業中はひときわ大きな異音を発してました。

HDDの記憶内容の消去

ファイルの退避が完了したら、次はddコマンドでHDDの記憶内容を消去します。


スポンサーリンク

root権限で以下のコマンドを実行します。

# dd if=/dev/urandom of=/dev/sdc bs=1M status=progress
# dd if=/dev/urandom of=/dev/sdc bs=1M status=progress
# dd if=/dev/zero of=/dev/sdc bs=1M status=progress

 

/dev/urandomからの入力は大事なことなので2回行い、確実に記憶されていた内容を書き潰します。

また、最近のddコマンドはコマンドラインオプションを追加することで進捗状況がわかるようになっているので、それも指定しています↓


スポンサーリンク

ddコマンドの実行に要した時間は以下のような感じでした。

  • /dev/urandomからの入力の場合で約10時間
  • /dev/zeroからの入力の場合で約4時間

作業の完了までに丸一日くらいかかりました。

交換作業

HDDの書き潰し作業が完了したところでHDDを取り外し、SSDに交換します。

取り付け前のSSDです。500GBです。

SSDを取り付けてみると、↑のような感じになります。


スポンサーリンク

内部のスペースを持て余し気味な感じになりますが、風通しがよくなるので引き続き使用するHDDにも優しい構成の変更だと思うことにします。

なお、ねじ止めなどは特に行っていません。

取り外した2TBのHDDです。

見た目は非常にきれいですが、ここでお役御免となります。

交換作業の完了後サーバ本体とHDDケースをUSBケーブルで接続してbootしてみると…

音が(ほぼ)ピタリと止みました!!

これで今回の作業の前半戦は終了です。

SSDのセットアップでハマった件

やりたいこと。

スポンサーリンク

ここまでは(時間はかかりますが)あまり難しい作業ではないのですが、ここからはちょっと難易度が上がるというか、少しでも問題が起きるとかなりハマる作業になります。

取り付けたSSDにはWindows10のシステムが入ったままになっていますので、これらをすべて消去し、Linux用のファイルシステムを構成する必要があります。

今どきのLinuxだとファイルシステムはXFSだと思いますので、いったんLVMの構成を行ってからその論理ボリュームとしてXFSのファイルシステムを作成することを最終的な目標としつつ、最初にLVMを使わずに作成したパーティションに直接XFSのファイルシステムをお試しで作ってみることにします。

ただ、容量が2TB→500GBになりますので、作成するXFSのファイルシステムは空き容量の全力を投入することにします。

LVMを使わずにXFSのファイルシステムを作成する。

まず最初にfdiskを使ってSSDにあったファイルシステム(リカバリ用なども含めて8個ありました。)をすべて削除します。

次にpartedを使って以下の手順でパーティションを1個作ります。なお、SSDに対応するデバイスファイルは/dev/sdcであるものとします。

  1. 以下のコマンドを実行し、開始セクタとして設定できる値を計算するためのパラメータを取得する[1]。
    # cat /sys/block/sdc/queue/optimal_io_size
    33553920
    # cat /sys/block/sdc/queue/minimum_io_size
    4096
    # cat /sys/block/sdc/alignment_offset
    0
    # cat /sys/block/sdc/queue/physical_block_size
    512

     

  2. 手順1で取得した値から(optimal_io_size+alignment_offset)/physical_block_sizeの値を計算し、開始セクタとして設定できる値を得る。手順1で取得した値を用いて計算すると、(33553920+0)/512=65535となる。
  3. partedを起動し、以下のコマンドを実行する。
    (parted) mkpart primary 65535s 100%

     

  4. 手順3に続けて以下のコマンドを実行し、alignmentが正しいかどうか確認する。なお、fdiskではalignmentされていない旨の警告が表示される場合がありますが、partedの方を信じることにします。
    (parted) align-check optimal 1
    1 アライメント済

     

パーティションが作成できたら、root権限で以下のコマンドを実行してファイルシステムを作成し、さらにそれがマウントできることを確認する。ここでも警告が表示されますが、見なかったことにします。なお、/warehouseはmount先のディレクトリです。

# mkfs.xfs /dev/sdc1
warning: device is not properly aligned /dev/sdc1
Use -f to force usage of a misaligned device
# mount -t xfs /dev/sdc1 /warehouse

 
ここまでの手順で、LVMを使わない方法ではありますが、ファイルシステムをマウントするところまでたどり着くことができました。

LVMの論理ボリューム上にXFSのファイルシステムを作成する。

問題が発生するまでの手順

SSDでもXFSのファイルシステムが作成できそうなことが確認できたところで、LVMの論理ボリューム上にファイルシステムを作成してみます。

前節で作成したXFSのファイルシステム及びパーティションをいったん削除し、以下の手順でLVM用のパーティションを作成します。

  1. 前節のパーティションの作成手順を手順1から手順4まで再度実行する。
  2. 以下のコマンドを実行し、LVM用のフラグをセットする。
    (parted) set 1 lvm on

     

また、root権限で以下のコマンドを実行し、作成したパーティションを使った物理ボリューム、ボリュームグループ(panda2)及び論理ボリューム(warehouse)を作成します。

# pvcreate /dev/sdc1
Physical volume “/dev/sdc1” successfully created.
# vgcreate panda2 /dev/sdc1
Volume group “panda2” successfully created
# lvcreate -n warehouse -L 300G panda2
Logical volume “warehouse” created.

 
さらに以下のコマンドを実行し、論理ボリューム(warehouse)上に適当な大きさのXFSのファイルシステムを作成します。

# mkfs.xfs /dev/panda2/warehouse
warning: device is not properly aligned /dev/panda2/warehouse
Use -f to force usage of a misaligned device

 
Warningが表示されますが、これについては前節でも発生していた(かつmountもできていた。)ので、無視して先に進めます。

問題発生

root権限で以下のコマンドを実行し、前節で作成したXFSのファイルシステムをmountしてみます。

すると…

# mount -t xfs /dev/panda2/warehouse /warehouse/
mount: /warehouse: wrong fs type, bad option, \
bad superblock on /dev/mapper/panda2-warehouse, \
missing codepage or helper program, or other error.

 
エラーメッセージ(実際は1行ですが、バックスラッシュで折り返しています。)が表示されてmountできません。😅

エラーメッセージの内容も「スーパーブロックに問題あり」のような物騒なメッセージが含まれていて、穏やかな話ではなさそうです。🤔

原因の分析と対処

前節のエラーメッセージを使ってGoogle先生に聞いてみたところ、参考文献[2]に行き当たり、LVM上の論理ボリューム(warehouse)上に作成したファイルシステムは(XFSに限らず)UUIDでファイルシステムを特定してマウントしていたのを思い出しました。

そこで、[2]の記述に従って、UUIDのチェックを無視するコマンドラインオプションを追加してmountコマンドを実行してみると…

# mount -t xfs -o nouuid /dev/panda2/warehouse /warehouse
# df -k
(中略)
/dev/mapper/panda2-warehouse 314419200 2225216 312193984 1% /warehouse

 
となり、mountできました。

-o nouuidオプションをいつまでも使うことはできないので、ファイルシステムをいったんunmountし、以下のコマンドを実行してUUIDを作り直します。

# xfs_admin -U generate /dev/panda2/warehouse
Clearing log and setting UUID
writing all SBs
new UUID = (作成されたUUID)

 

そして、再度mountしてみると…

# mount -t xfs /dev/panda2/warehouse /warehouse
# df -k
(中略)
/dev/mapper/panda2-warehouse 314419200 2225216 312193984 1% /warehouse

 
無事、mountできました!!

問題解決です。(｀・ω・´)

仕上げ

問題が解決したら、以下の作業を行うとSSDのセットアップ作業を完了させることができます。

  1. /etc/fstabに前節で作成したUUIDを設定して保存する。
  2. xfs_growfsコマンドを使ってファイルシステムのサイズを論理ボリュームに割り当てているサイズと同じにする(=目一杯大きくする)。
  3. rebootする。

お疲れ様でした。😎

まとめ

ファイルシステムのセットアップ作業では割とありがちな、表示されているエラーメッセージを素直に読んだだけでは解決策につながらない状況でしたが、Google先生の力を借りて何とか解決できて良かったです。😄

UUIDはノーマークでしたね。

取り外した2TBのHDDは後から買ったものでしたが、以前白金に住んでいた時にほこりや熱がこもり易い環境で24時間運転で使用したせいか、異音を発するようになりました。

横浜に引っ越してきてからも使用可能なストレージが確保できなかったために使い続けてきましたが、今回dynabookから取り外したSSDが使えそうだったので、交換することにしました。

交換したところ、音が発生することが(ほぼ)なくなりましたので、しばらくこのまま使ってみたいと思います。

この記事は以上です。

References / 参考文献

  1. How to Fix: “warning: device is not properly aligned” with Parted
  2. mount: wrong fs type, bad option, bad superblock on /dev/xvdf1, missing codepage or helper program, or other error

Related Posts / 関連ページ

Acer E3-112-F14C/SのHDDをSSDに換装してみたところ、OSの起動と終了がとりあえず速くなった件(2/2: ドライブの交換作業)。 Fedora 27で久々にSamba4を動かしてみた。 dynabook R732/37HKのストレージを2TBのSSDに交換してみた件。 IPNSを使いたいのでIPFSのdaemonのnamesys-pubsubオプションを有効にしてみた。