プロフィール

Extrose
2002年頃から電脳海にいる。制作ペースは激減したものの今でも現役の作曲者(自称)であり、機会があればBMSも作る。が、最近はVを被ってゲーム実況に勤しんでいる。興味があるものになんでも手を出すのでかなりの趣味を抱えている。

柊雷夜
ユーチューブ地方で見かけるVのすがた (↑)。たまに VRChat にも出る。 VRoid Studio 製。

リリース

個人活動

実績(依頼など)

読み物

[Alma Linux 9] ストレージのマウントを行う

関係：Alma Linux 9 なので、それより前のバージョンや、CentOS / Red Hat などでも転用可能

概要

HDD(昨今であれば仮想マシンなので、仮想ディスクのことが多いと思われる)を環境に追加した後、OSで利用できる状態にする

手順

1. fdisk を用いてパーティションを作成

# 注：「?」はデバイス状況により異なる。fdisk -l で確認
fdisk /dev/sd?

パーティションを要件通りに作成する
全領域を1パーティションにする場合はn、デフォルトでEnterやりきり、wで確定

この手順については、ディスクの容量が2TBを超えるなら parted のほうが良いとのこと

2. 初期化

# 注：「n」はパーティション番号 (先のfdiskで作ったもの、例えば sda1 で作ったなら、以後 /dev/sda1 と指定)
mkfs.ext4 /dev/sd?n

パーティションを切っただけではまだ使えないので、初期化を行う

3. マウントする

mount -t ext4 /dev/sd?n <マウント先のディレクトリ>

マウント先のディレクトリは作っておくこと
即座に再起動できるなら当手順を飛ばして次を行っても良い

4. マウントを恒久的に行う

# UUIDを取得
blkid /dev/sd?n

vi /etc/fstab

# 下記を追記
# echoでの追記も理屈として可能だが、/etc/fstab に誤った内容があるとOS起動に失敗しリカバリモードでの操作(Teratermなどで接続できない)が必要となるため、安全のためにもエディタを用いることをおすすめする
UUID=(調べたUUID) <マウント先のディレクトリ> ext4 defaults 0 2

UUIDを指定してマウントを行うよう設定する
再起動しても、この設定を基にマウントが行われる

余談：なぜこんな記事を？ (1, 慣習に対する注意喚起)

かつての手順は下記にしていた

fdisk /dev/sd?
mke2fs /dev/sd?n
mount -t ext4 /dev/sd?n <マウント先のディレクトリ>

vi /etc/fstab
/dev/sd?n <マウント先のディレクトリ> ext4 defaults 0 2

※ mke2fs のところは私の理解力不足なのでスルーしてほしい

注視いただきたいのは /etc/fstab の編集内容である

多くのチュートリアルなどで、/etc/fstab に追記する際は /dev/sd?n ～と書くと見かけた人も多いと思うが、これは CentOS 5～7頃時代の、今や古い記法となる
つまり、 この時期に Linux を勉強したエンジニアが、今でもこの記法を行っている可能性がある

/dev/sd?n については、OSの何らかのタイミングにより変動する箇所のため、マウントが突然入れ替わることが起こりうる
これを固定化するのが先述のUUIDを指定する方法となる

ちなみに UUID を指定する記法は CentOS 5 からできた様子

余談：なぜこんな記事を？ (2, 個人的な事件)

こんな構成のNASを仮想マシンに構築していた

  ESXi      - CentOS(NAS)
    |       /(マウント)
USB HDD 4台

ESXi にUSBHDDを4台接続し、それを仮想マシンにマウント、NASとして運用していたというものである
ここで、USB HDD は2台ずつに分け、データ2系統ごとにマスターとバックアップの計4台という構成をしていた

HDD	内容
HDD 1	1系統マスター
HDD 2	1系統バックアップ (cron + rsync により 1系統マスターの内容を同期しバックアップ)
HDD 3	2系統マスター
HDD 4	2系統バックアップ (cron + rsync により 2系統マスターの内容を同期しバックアップ)

あるとき、あるデータが無いことに気づき調査をすると、2系統のマスターのデータが2系統のマスターと同一になっていることに気づいた
これにより、更に2系統目のバックアップも、1系統のデータに置き換わっていることも確認できた

HDD	内容
HDD 1	1系統マスター
HDD 2	1系統バックアップ (cron + rsync により 1系統マスターの内容を同期しバックアップ)
HDD 3	2系統マスターのはずが1系統のデータがある
HDD 4	2系統バックアップのはずが1系統のデータがある

なぜこのようなことが起こったかと言えば、突如 CentOS がデバイスの認識順を入れ替えたためである
つまり、下記のようになったということである

HDD	内容
HDD 1	1系統マスター
HDD 2 ⇒ HDD 3 に	1系統バックアップ (cron + rsync により 1系統マスターの内容を同期しバックアップ)
HDD 3 ⇒ HDD 2 に	2系統マスターのはずが1系統のデータがある
HDD 4	2系統バックアップのはずが1系統のデータがある

これにより2系統のデータは失われ、CentOSのデバイス管理に信用を持てなくなった私はESXi 及び CentOS によるNAS運用構成を廃止
ローカルPCに必要時に接続する方法に変更した

ということを最近思い出し、根本的な原因は何かわかるだろうかと思って ChatGPT 4o に問い合わせた結果、
/dev/sd?n をマウントする方法が慣習によるもので、UUIDを用いた方法に是正すべきであるという内容を得たので、この記事を書いたという経緯である

UUIDでマウントすることでこのような悲劇を防げる
・・・とはいえ本事象はトラウマなので、これからも外部サーバーでNASを作ることは無かろう

更なる余談だが、この2系統のデータとは、「クラブイベント The Novice で録画していたイベントの様子」が入ったもの
後日、知人によりいくらか補完はできたものの、大部分が失われたままとなった
逆に言えば「思い出にあるもの」が消えただけであり、作業用データなどが無かったのが幸いと言える

Stoic Sounds 元はExtroseが運営する個人サイト名