Linux の 101 試験対策: ファイルシステムの整合性の維持

ディスク・スペースの使用状況を追跡する

Linux ファイルシステムの整合性をチェックする方法、空きスペースを監視する方法、そしてファイルシステムでの単純な問題を修復する方法を学んでください。Linux のシステム管理者として認定するための LPI (Linux Professional Institute) 101 試験に備えて勉強するために、そしてシステムが損傷した後や電源断が発生した後は言うまでもなく、単にファイルシステムをチェックして、良好な状態に保つために、このチュートリアルの内容を利用してください。

Ian Shields, Linux Author, IBM

Ian ShieldsIan Shields は、Linux のフリー・ライターです。ノースカロライナ州 Research Triangle Park にある IBM を退職した彼が、オーストラリアのキャンベラにある IBM にシステム・エンジニアとして入社したのが 1973年であり、それ以降、カナダのモントリオールやノースカロナイナ州 Research Triangle Park でシステム・エンジニアリングとソフトウェア開発の両方に携わってきました。1990年代後半からは、Linux を使用して Linux 上で開発を行うとともに、Linux に関する執筆も行ってきました。彼は、オーストラリア国立大学で純粋数学および哲学の学士号を取得し、ノースカロライナ州立大学でコンピューター・サイエンスの修士号と博士号を取得しています。普段はオリエンテーリングを楽しんでおり、旅行に行くのも好きです。


developerWorks 貢献著者レベル

2016年 5月 12日 (初版 2010年 8月 24日)

概要

より詳しく学び、さらなる開発を行い、より多くの人とつながる

新たに登場した developerWorks Premium メンバーシップ・プログラムでは、メンバーになると、強力な開発ツールのほか、Safari Books Online を通じて提供される最もホットな 500 タイトルの技術書 (Linux 開発者向けのものが大量にあります) を含む各種のリソースをすべて自由に利用できるようになります。さらに、主要な開発者向けイベントの登録料の大幅な割引や、最新の O'Reilly カンファレンスの全容を閲覧できる再生動画など、その他にもさまざまな特典が提供されます。今すぐサインアップしてください

このチュートリアルで説明する内容は以下のとおりです。

  • ファイルシステムの整合性を確認する方法
  • 空きスペースと i ノードを監視する方法
  • ファイルシステムでの単純な問題を修復する方法

このチュートリアルでは、標準ファイルシステムとジャーナリング・システムを取り上げ、ext2 (標準ファイルシステム) と ext3 (ジャーナリング・ファイルシステム) に重点を置いて説明しますが、これ以外のファイルシステムのツールについても紹介します。


なぜファイルシステムをチェックするのか?

システムが損傷したり、電源断が発生したりすると、Linux では正常にファイルシステムをアンマウントできなくなることがあります。その場合、ファイルシステムの一部では変更が完了し、他の部分では変更が完了していないという、一貫性のない状態になる可能性があります。損傷したファイルシステムをそのまま操作するのは、既存のエラーをさらに悪化させることになるため、良い考えとは言えません。

十分なファイルシステム管理用スペース (つまり、i ノード) を持つファイルシステムが、操作を継続する上でスペースが不足している場合、他の問題が生じる可能性があります。そこでこのチュートリアルでは、こうした問題を扱う上で役立ついくつかのツールを紹介します。

この連載について

この連載は Linux システム管理タスクの学習に役立つだけでなく、Linux Professional Institute の LPIC-1: Linux Server Professional Certification 試験に備えるための教材にもなります。

連載の各チュートリアルに関する説明とリンクについては、developerWorks の「Linux の 101 試験対策: LPIC-1 のロードマップ」を参照してください。現在進行中のこのロードマップは、2015年 4月 15日に更新された LPIC-1 試験の項目のバージョン 4.0 を反映しています。完成したチュートリアルは、その都度ロードマップに追加されていきます。

このチュートリアルは、LPIC-1: Linux Server Professional Certification 101 試験における主題 104 の項目 104.2 に備える上で役に立ちます。この項目は、重要度が 2 とされています。

前提条件

この連載のチュートリアルを最大限に活用するには、Linux の基礎知識と、チュートリアルに記載されたコマンドを演習できる実際の Linux システムが必要です。プログラムのバージョンによって出力のフォーマットに違いが出てくる場合もあるため、コマンドの実行結果は必ずしもここに記載するリストや図とまったく同じであるとは限りません。このチュートリアルのほとんどの例で使用しているのは、CentOS 6 (カーネル 2.6.32) です。他のシステムでは、結果が異なる場合もあります。

また、チュートリアル「Linux の 101 試験対策: パーティションおよびファイルシステムの作成」で説明している内容についても十分に理解している必要があります。


ファイルシステムをチェックするツール

ファイルシステムをチェックするための主要なツールは fsck です。fsck は mkfs と同じく、さまざまなタイプのファイルシステムに対応する各種ファイルシステム・チェック・ルーチンのまさにフロントエンドとなります。リスト 1 に、これらのチェック・ルーチンのいくつかを記載します。

リスト 1. fsck プログラムの抜粋
[ian@attic4-cent ~]$ ls /sbin/*fsck*
/sbin/btrfsck  /sbin/fsck         /sbin/fsck.ext3     /sbin/fsck.msdos
/sbin/dosfsck  /sbin/fsck.cramfs  /sbin/fsck.ext4     /sbin/fsck.vfat
/sbin/e2fsck   /sbin/fsck.ext2    /sbin/fsck.ext4dev  /sbin/fsck.xfs

意外に思えるかもしれませんが、これらのファイルのうちのいくつかは、たった 1 つのファイルに対して張られたハード・リンクです (リスト 2 を参照)。これらのプログラムは、ブート・プロセスが開始されて早々に使用される場合があるため、ファイルシステムがマウントされていなかったり、シンボリック・リンクがサポートされていなかったりする可能性があります。ハード・リンクとシンボリック・リンクについての詳細は、チュートリアル「Linux の 101 試験対策: ハード・リンクとシンボリック・リンクの作成および変更」で説明しています。

リスト 2. 1 つの fsck プログラムが持つさまざまな顔
[ian@attic4-cent ~]$ find /sbin -samefile /sbin/e2fsck
/sbin/fsck.ext3
/sbin/fsck.ext4
/sbin/e2fsck
/sbin/fsck.ext4dev
/sbin/fsck.ext2

システム・ブート・プロセスでは、-A オプションを指定した fsck を使用してファイルシステムのチェックを行います。チェックの対象となるのは、ルート・ファイルシステムと、/etc/fstab 制御ファイルの中でチェック対象として指定された他のすべてのファイルシステムです。ファイルシステムが正常にアンマウントされなかった場合には整合性チェックが行われ、安全に修復できる場合には修復措置が採られます。この整合性チェックを制御するのは、/etc/fstab エントリーの pass (または passno) フィールド (6 番目のフィールド) です。pass フィールドが 0 に設定されたファイルシステムは、ブート時のチェック対象にはなりません。ルート・ファイルシステムの pass フィールドの値は 1 なので、ルート・ファイルシステムが最初にチェックされます。ルート以外のファイルシステムについては、一般に pass フィールドの値が 2 (またはそれよりも高い値) に設定されます。この値が、チェックの順番を指定します。

複数の fsck 処理を並列に実行することにはメリットがあるという判断をシステムが下した場合、並列に実行することができます。そのため、リスト 3 に示す /grubfile ファイルシステムと /home/ian/data ファイルシステムのように、異なるファイルシステムに同じ pass 値を設定することができます。ただし、fsck は同じ物理ディスク上で複数のファイルシステム・チェックを実行することはしません。/etc/fstab のレイアウトに付いての詳細は、fstab の man ページを参照してください。

リスト 3. /etc/fstab のエントリーで指定されたブート時のファイルシステム・チェック
filesystem              mount point                               type    options      dump pass
UUID=2f60a3b4-ef6c-4d4c-9ef4-50d7f75124a2 /                       ext3    defaults        1 1
UUID=3c3de27e-779a-44d5-ad7a-61c5fd03d9e7 /grubfile               ext3    defaults        1 2
UUID=158d605e-2591-4749-bf59-5e92e1b1c01d swap                    swap    defaults        0 0
tmpfs                                     /dev/shm                tmpfs   defaults        0 0
devpts                                    /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                                     /sys                    sysfs   defaults        0 0
proc                                      /proc                   proc    defaults        0 0
UUID=4c962b67-c646-467f-96fb-cbbd6de40140 /home/ian/data          ext4    defaults        1 2
UUID=0998d33c-3398-463d-b0e3-7c13ca0c675f /home/ian/research      ext3    defaults        1 2
UUID=e3be4658-b79b-470d-82fe-bb434bcdcc2f /home/ian/pictures      ext4    defaults        1 2

一部のジャーナリング・ファイルシステム (ReiserFS、XFS など) では、pass の値が 0 に設定されることもあります。これらのジャーナリング・システムでは、fsck ではなく、ジャーナリング・コードがファイルシステムの整合性チェックと修復を行うためです。その一方、/proc などのファイルシステムは初期化時に作成されるため、チェックを実行する必要はありません。

ファイルシステムのチェックは、システムがブートした後に行うことができます。ファイルシステムをチェックするには、root 権限を持っていること、そしてチェック対象のファイルシステムをまずアンマウントすることが必要となります。リスト 4 に、ファイルシステムのうちの 2 つを、デバイス名、ラベル、または UUID を使用してチェックする方法を示します。blkid コマンドを使用して、ラベルまたは UUID を指定してデバイスを検索することも、デバイスを指定してラベルと UUID を検索することもできます。

リスト 4. fsck を使用したファイルシステムのチェック
[root@attic4-cent ~]# # Find label and UUID for /dev/sdc4
[root@attic4-cent ~]# blkid /dev/sdc4
/dev/sdc4: LABEL="IAN-GPT-EXT4" UUID="f69e0b28-beda-4255-ad5a-4d73672ac9e4" TYPE="ext4" 
[root@attic4-cent ~]# # Check /dev/sdc4
[root@attic4-cent ~]# fsck /dev/sdc4
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
IAN-GPT-EXT4: clean, 11/2424832 files, 197218/9681152 blocks
[root@attic4-cent ~]# # Check it by label using fsck.ext4
[root@attic4-cent ~]# fsck.ext4 LABEL=IAN-GPT-EXT4
e2fsck 1.41.12 (17-May-2010)
IAN-GPT-EXT4: clean, 11/2424832 files, 197218/9681152 blocks
[root@attic4-cent ~]# # Check it by UUID using e2fsck
[root@attic4-cent ~]# e2fsck UUID=f69e0b28-beda-4255-ad5a-4d73672ac9e4
e2fsck 1.41.12 (17-May-2010)
IAN-GPT-EXT4: clean, 11/2424832 files, 197218/9681152 blocks
[root@attic4-cent ~]# # Finally check the small vfat partition /dev/sda3
[root@attic4-cent ~]# fsck /dev/sda3
fsck from util-linux-ng 2.17.2
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
/dev/sda3: 0 files, 0/1265 clusters

マウントされた状態のファイルシステムをチェックしようとすると、警告が出されることがあります。最近のバージョンの fsck では、リスト 5 に示すようにチェックはアボートされるはずです (リスト 5 では、ルート・ファイルシステムをチェックしようとしています)。チェックがアボートされない場合には、警告に従うようにして、マウントされた状態のファイルシステムはチェックしないでください。

リスト 5. マウントされたファイルシステムをチェックしようとしないこと
[root@attic4-cent ~]# df /
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda11      79040416 7444796  67580568  10% /
[root@attic4-cent ~]# fsck /dev/sda11
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
/dev/sda11 is mounted.
e2fsck: Cannot continue, aborting.

ファイルシステムで実行するチェックを fsck に判断させるのも賢明な方法です。誤ったチェックを実行すると、ファイルシステムが壊れることになりかねません。fsck が特定のファイルシステム、またはファイルシステム一式で実行するチェック内容を表示するには、リスト 6 に示すように -N オプションを使用します。

リスト 6. fsck による /dev/sda11、/dev/sdb* のチェック内容の表示
[root@attic4-cent ~]# fsck -N /dev/sda11 /dev/sdb*
fsck from util-linux-ng 2.17.2
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 /dev/sda11 
[/sbin/fsck.ext2 (2) -- /dev/sdb] fsck.ext2 /dev/sdb 
[/sbin/fsck.ext3 (3) -- /dev/sdb1] fsck.ext3 /dev/sdb1 
[/sbin/fsck.ext4 (4) -- /home/ian/data] fsck.ext4 /dev/sdb2 
[/sbin/fsck.ext3 (5) -- /home/ian/research] fsck.ext3 /dev/sdb3 
[/sbin/fsck.ext4 (6) -- /dev/sdb4] fsck.ext4 /dev/sdb4

ここまでは、ext および vfat ファイルシステムをチェックしてきましたが、今度は /dev/sdc3 のXFS ファイルシステムをチェックしてみましょう。リスト 7 を見るとわかるように、この場合、fsck コマンドは xfs_check コマンドを使用するように指示するだけです。エラーが発生しなければ、xfs_check は何の出力も表示しません。詳細を出力するための -v オプションもありますが、このオプションを指定した場合の出力は、単純なチェックには詳細すぎます。

リスト 7. fsck を XFS で使用する場合
[root@attic4-cent ~]# fsck -N /dev/sdc3
fsck from util-linux-ng 2.17.2
[/sbin/fsck.xfs (1) -- /dev/sdc3] fsck.xfs /dev/sdc3 
[root@attic4-cent ~]# fsck /dev/sdc3
fsck from util-linux-ng 2.17.2
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_check(8) and xfs_repair(8).
[root@attic4-cent ~]# xfs_check /dev/sdc3

空きスペースの監視

ストレージ・デバイスでは、ファイルまたはディレクトリーは一連のブロックのなかに格納されます。ファイルに関する情報が格納されるのは i ノードです。ここには、所有者、ファイルの最終アクセス時刻、ファイルのサイズ、ファイルがディレクトリーであるかどうか、ファイルの読み取りまたは書き込みが許可されているユーザーなどの情報が記録されます。i ノード番号はファイル・シリアル番号としても知られており、個々のファイルシステム内でそれぞれに固有です。ファイルとディレクトリーについての詳細は、チュートリアル「Linux の 101 試験対策: ファイルとディレクトリーの管理」を参照してください。

ファイルシステムではデータ・ブロックと i ノードがスペースを占めます。そのため、スペースの使用状況を監視して、ファイルシステムを拡大するだけのスペースが確実に残されているようにする必要があります。

df コマンド

df コマンドは、マウントされているファイルシステムに関する情報を表示します。このコマンドに -T オプションを指定すればファイルシステムのタイプも表示されますが、このオプションを追加しない限り、ファイルシステムのタイプは表示されません。上記で使用した CentOS 6 システムの場合、df コマンドによる出力はリスト 8 のようになります。ここでは参考までに、/mnt/btrfs-test にマウント・ポイントを作成して、そこに Btrfs ファイルシステム (/dev/sdc5) をマウントしました。vfat に関しても同じことを行い、/mnt/vfat-test にマウント・ポイントを作成して、そこに /dev/sda3 上の小さな vfat パーティションをマウントしました。

リスト 8. ファイルシステムの使用状況の表示
[root@attic4-cent ~]# mkdir /mnt/btrfs-test
[root@attic4-cent ~]# mount /dev/sdc5 /mnt/btrfs-test
[[root@attic4-cent ~]# mkdir /mnt/vfat-test
[root@attic4-cent ~]# mount /dev/sda3 /mnt/vfat-test
root@attic4-cent ~]# df -T
Filesystem     Type  1K-blocks      Used Available Use% Mounted on
/dev/sda11     ext3   79040416   7444800  67580564  10% /
tmpfs          tmpfs   1961548       232   1961316   1% /dev/shm
/dev/sda1      ext3     988420    116067    821349  13% /grubfile
/dev/sdb2      ext4  124077136  49155856  68611636  42% /home/ian/data
/dev/sdb3      ext3   60458064  30808664  26578276  54% /home/ian/research
/dev/sdc1      ext4  467126880 134497524 308894012  31% /home/ian/pictures
/dev/sda5      ext4   71168700  31178752  36368096  47% /mnt/sda5
/dev/sdc5      btrfs  39062528        56  36936704   1% /mnt/btrfs-test
/dev/sda3      vfat       2530         0      2530   0% /mnt/vfat-test

出力にはブロックの合計数と、使用中のブロックの数、空きブロック (使用可能なブロック) の数が示されていることに注目してください。また、ファイルシステム (/dev/sda11 のルート・ファイルシステムの場合は ext3) とそのマウント・ポイント (/) にも注目してください。tmpfs は、仮想メモリーのファイルシステムのエントリーです。これらの仮想ファイルシステムは RAM またはスワップ・スペースの中だけに存在し、mkfs コマンドを実行しなくても、マウントするだけで作成されます。

i ノードの使用状況に関する具体的な情報を表示するには、df コマンドに -i オプションを指定します。さらに -x オプションを使って特定のファイルシステム・タイプを除外することも、-t オプションを使って特定のファイルシステム・タイプだけに情報を絞り込むこともできます。これらのオプションは、必要に応じてファイルシステム・タイプごとに繰り返し指定します。リスト 9 の例を見てください。

リスト 9. i ノードの使用状況の表示
[root@attic4-cent ~]# df -i -x tmpfs
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/sda11      5021696 236498  4785198    5% /
/dev/sda1        251000    537   250463    1% /grubfile
/dev/sdb2       7904304 125115  7779189    2% /home/ian/data
/dev/sdb3       3842048  40341  3801707    2% /home/ian/research
/dev/sdc1      29671424  48944 29622480    1% /home/ian/pictures
/dev/sda5       4530176 245603  4284573    6% /mnt/sda5
/dev/sdc5             0      0        0     - /mnt/btrfs-test
/dev/sda3             0      0        0     - /mnt/vfat-test
[root@attic4-cent ~]# df -iT -t ext4 -t vfat
Filesystem     Type   Inodes  IUsed    IFree IUse% Mounted on
/dev/sdb2      ext4  7904304 125115  7779189    2% /home/ian/data
/dev/sdc1      ext4 29671424  48944 29622480    1% /home/ian/pictures
/dev/sda5      ext4  4530176 245603  4284573    6% /mnt/sda5
/dev/sda3      vfat        0      0        0     - /mnt/vfat-test

驚くことではないかもしれませんが、FAT32 ファイルシステムには i ノードがありません。一方で、Btrfs ファイルシステムに i ノード情報がないことには、ちょっと驚くかもしれません。Btrfs では (そして ReiserFS も)、動的に割り当てられた構造に i ノード情報を保持するので、ext2、ext3、ext4 などには存在していた特殊な i ノード・ブロックはありません。

df コマンドにはこの他にも、表示をローカル・ファイルシステムに制限したり、出力フォーマットを制御したりするためのオプションがあります。例えば、ファイル・サイズを人間にとってわかりやすい単位 (1024 を 1K で表現するなど) で表示する -H オプション、サイズを 10 の累乗 (1K=1000) にする -h (または --si) オプションなどです。

ディレクトリー・ツリーの特定の部分がどのファイルシステムにあるのか確信が持てない場合には、df コマンドにディレクトリー名のパラメーター、あるいはファイル名自体を指定することができます (リスト 10 を参照)。

リスト 10. df の読みやすい出力
[root@attic4-cent ~]# df --si ~ian/index.html
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda11       81G  7.7G   70G  10% /

tune2fs コマンド

ext 系列のファイルシステムには、ブロック数に関する情報の他に、ファイルシステムにジャーナル機能があるか (ext3 または ext4)、ジャーナル機能がないか (ext2) を調べるために使える tune2fs というユーティリティーもあります。このコマンドではまた、多数のパラメーターを設定したり、ジャーナルを追加して ext2 ファイルシステムを ext3 に変換したりすることもできます。リスト 11 に、新しく作成された ext4 ファイルシステムに関する出力を示します。ここでは -l オプションを使用して、既存の情報だけを表示しています。

リスト 11. tune2fs による ext4 ファイルシステムに関する情報の表示
[root@attic4-cent ~]# tune2fs -l /dev/sdc4
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   IAN-GPT-EXT4
Last mounted on:          <not available>
Filesystem UUID:          f69e0b28-beda-4255-ad5a-4d73672ac9e4
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg 
sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2424832
Block count:              9681152
Reserved block count:     484057
Free blocks:              9483934
Free inodes:              2424821
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1021
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              1
Flex block group size:    16
Filesystem created:       Wed Aug  5 10:58:58 2015
Last mount time:          n/a
Last write time:          Thu Aug  6 10:04:27 2015
Mount count:              0
Maximum mount count:      23
Last checked:             Wed Aug  5 10:58:58 2015
Check interval:           15552000 (6 months)
Next check after:         Mon Feb  1 09:58:58 2016
Lifetime writes:          725 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      cb683b6a-2ef7-4588-954a-d163b0219652
Journal backup:           inode blocks

xfs_info

XFS ファイルシステムの場合には、xfs_info を使用して、mkfs.xfs がファイルシステムの作成時に表示する情報と同じ情報を表示することができます (リスト 12 を参照)。xfs_info は、マウントされているファイルシステムで使用する必要があります。

リスト 12. xfs_info による XFS ファイルシステムに関する情報の表示
[root@attic4-cent ~]# mkdir /mnt/xfs-test
[root@attic4-cent ~]# mount /dev/sdc3 /mnt/xfs-test
[root@attic4-cent ~]# xfs_info /mnt/xfs-test
meta-data=/dev/sdc3              isize=512    agcount=16, agsize=655360 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=10485760, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=5120, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1

du コマンド

df コマンドは、ファイルシステム全体に関する情報を表示しますが、ホーム・ディレクトリーが使用しているスペースの量や、/usr を専用のファイルシステムに移した場合に使用できるパーティションの大きさを知りたいという場合もあります。そのような場合には、du コマンドを使用すると、それらの情報を得ることができます。

du コマンドにファイル名 (複数可) をパラメーターとして指定すると、そのファイルに関する情報が表示されます。ディレクトリー名を指定すると、du は再帰処理を行い、指定されたディレクトリーに含まれるすべてのファイルとサブディレクトリーのサイズを計算します。したがって、出力が膨大な量になる可能性がありますが、幸い -s オプションを使用することで、ディレクトリーの合計サイズだけを計算するように指定することができます。du を使用して複数のディレクトリーの情報を取得する場合には、-c オプションを追加することで、総計を取得することが可能です。出力フォーマットについても、df で使用するサイズ関連のオプションと同じ一式 (-h-H--si など) を使って制御することができます。リスト 13 は、新しく作成したユーザーのホーム・ディレクトリーに関する 2 通りの情報を表示したものです。このユーザーはいったんログインして index.html ファイルを作成しました。

リスト 13. du の使用
[testuser@attic4-cent ~]$ du -hc *
4.0K	Desktop
4.0K	Documents
4.0K	Downloads
16K	index.html
4.0K	Music
4.0K	Pictures
4.0K	Public
4.0K	Templates
4.0K	Videos
48K	total
[testuser@attic4-cent ~]$ du -hs .
980K	.

du -c * で取得した総計 48 K と、du -s で取得した集計 980 K が異なる理由は、後者にはドットで始まるエントリー (.bashrc など) が含まれる一方、前者にはこれらのエントリーが含まれないためです。

du に関してもう 1 つ注意すべき点は、コマンドを実行する対象ディレクトリーの読み取り権限を持っていなければならないことです。

ここで du を使用して、/usr ツリーが使用しているスペースの合計量と、その第 1 レベルのサブディレクトリーのそれぞれが使用しているスペースの量を表示してみましょう。その結果は、リスト 14 に示すとおりです。その際、root 権限を使用して適切なアクセス権があるようにしてください。

リスト 14. /usr で du を使用する例
[root@attic4-cent ~]# du -shc /usr/*
257M	/usr/bin
4.0K	/usr/etc
4.0K	/usr/games
132M	/usr/include
383M	/usr/lib
1.5G	/usr/lib64
62M	    /usr/libexec
136K	/usr/local
67M	    /usr/sbin
2.4G	/usr/share
98M	    /usr/src
0	    /usr/tmp
4.8G	total

ファイルシステムの修復

時として (頻繁でないことを祈ります)、ファイルシステムが損傷したり正常にアンマウントできなかったりするなどの理由によって最悪の事態が発生し、ファイルシステムを修復しなければならないことがあります。上記で説明した fsck コマンドは、ファイルシステムをチェックするだけでなく、ファイルシステムを修復することも可能です。大抵はブート時の自動チェックによって問題が修復されるので、ファイルシステムをそのまま使い続けられます。

ブート時のファイルシステムの自動チェックで整合性を回復できない場合には、シングル・ユーザー・モードのシェルが起動され、fsck を手動で実行するよう何らかの指示が出されます。ジャーナリング・ファイルシステムではない ext2 の場合、ファイルシステム上の特定のブロックを修復するために提案されるアクションを実行してもよいかどうかを尋ねる一連の確認リクエストが表示されることになるでしょう。一般に、これらのリクエストには「y」(はい) と応答して、fsck に問題の修復を任せるべきです。その場合、システムがリブートしてから、欠落しているデータやファイルがないかどうかを調べてください。

ファイルシステムの損傷が疑われる場合、あるいは手動でチェックを実行したい場合、大抵のチェック・プログラムではファイルシステムをアンマウントするか、少なくとも読み取り専用でマウントすることが必要となります。けれども実行中のシステムではルート・ファイルシステムをアンマウントすることができません。そのため最善の策となるのは、シングル・ユーザー・モードに移行して (telinit 1を使用)、ルート・ファイルシステムを読み取り専用で再マウントすることです。これで、整合性チェックを実行できるようになります。さらに望ましいファイルシステムのチェック方法は、ライブ CD や USB メモリー・キーなどのリカバリー・システムをブートし、リカバリー・システムから、アンマウントされたファイルシステムのチェックを実行することです。

fsck で問題を修復できなくても、他に使用できるツールはあります。けれどもファイルシステムを正常に修復するためには、ファイルシステムのレイアウトに関する高度な知識が必要になるのが通常です。

なぜジャーナルなのか

ext2 ディスクの fsck スキャンは、完了するまでに相当な時間がかかることがあります。これは、ファイルシステムの内部データ構造 (またはメタデータ) を完全にスキャンしなければならないためです。ファイルシステムが大きくなるにつれ、スキャンにかかる時間は長くなります。これはディスクの速度が速くなったとしても変わらないので、完全なチェックに 1 時間以上かかってしまう可能性もあります。

この問題がきっかけとなって生まれたのが、ジャーナル機能を持つファイルシステム、つまりジャーナリング・ファイルシステムです。ジャーナリング・ファイルシステムは、最近行われた変更のログをファイルシステム・メタデータに保持します。ファイルシステムが損傷した後、ファイルシステムのドライバーはログを調べ、ファイルシステムの最近の変更箇所のうち、エラーが含まれている可能性がある箇所を判断します。この設計変更により、ジャーナリング・ファイルシステムの整合性チェックは、ファイルシステムのサイズとは関係なく、ものの数秒で行われるようになります。さらに、ファイルシステムのドライバーはマウントされたファイルシステムをチェックするのが通常なので、外部 fsck チェックは一般に不要となります。実際、xfs ファイルシステムにとって fsck は何の意味も持ちません!

ファイルシステムの手動チェックを実行する場合は、該当する fsck コマンド (fsck.ext3e2fsckxfs_check など) の man ページを調べて、適切なパラメーターを判断してください。-p オプションを ext2、ext3、または ext4 ファイルシステムで使用すると、安全に修復できる問題であれば、fsck が自動的にすべての問題を修復します。実際、これがブート時に行われることです。

この後 e2fsckxfs_check の使用方法を説明するため、空の XFS ファイルシステムで e2fsck を実行した後、これを修復するために xfs_check を使用します。前に、適切なチェッカーを使用していることを確実にするためには、fsck フロントエンドを使用するように提案したこと、そしてその提案のとおりにしないとファイルシステムが壊れる可能性があると警告したことを思い出してください。

リスト 15 ではまず、XFS ファイルシステムが含まれる /dev/sda8 に対して e2fsck を実行しています。少しやりとりをした後、ctrl-Break を使って中断しようとしていますが、これでは遅すぎます。警告: ファイルシステムを壊そうとするのでない限り、この操作は決して行わないでください。

リスト 15. XFS ファイルシステムで e2fsck を意図的に手動で実行する例
[root@attic4-cent ~]# xfs_check -s /dev/sdc3
[root@attic4-cent ~]# e2fsck /dev/sdc3
e2fsck 1.41.12 (17-May-2010)
e2fsck: Group descriptors look bad... trying backup blocks...
/dev/sdc3 was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate<y>? yes

Pass 1: Checking inodes, blocks, and sizes
Deleted inode 163841 has zero dtime.  Fix<y>? ctrl-Break

/dev/sdc3: e2fsck canceled.

/dev/sdc3: ***** FILE SYSTEM WAS MODIFIED *****

最初のプロンプトで中断したとしても、XFS ファイルシステムが損傷することに変わりはありません。私に続いて声に出して言ってください。「ファイルシステムを壊そうとするのでない限り、この操作は決して行わないでください。」

今度は xfs_check を使って XFS ファイルシステムをチェックします。xfs_check コマンドはかなり冗長ですが、このコマンドには、重大なエラーだけを報告する -s オプションがあります。このオプションを指定した場合の出力をリスト 16 に示します。

リスト 16. xfs_check による XFS ファイルシステムの修復
[root@attic4-cent ~]# xfs_check -s /dev/sdc3
xfs_check: cannot init perag data (117)
blocks 17039360/3..3 claimed by block 17039360/0
can't seek in filesystem at bb 89335319756824
can't read agfl block for ag 17039360
can't seek in filesystem at bb 89335588200448
can't seek in filesystem at bb 89335319756800
can't seek in filesystem at bb 89335319756800

XFS ファイルシステムを修復するには、xfs_repair コマンドを使用する必要があります。これも xfs_check と同じくかなり冗長なコマンドですが、このコマンドには -s オプションがありません。実際に修復するのではなく、何を修復しなければならないかを調べるだけの場合には、xfs_repair -n を使用してください。リスト 17 に xfs_repair の出力の一部を示します。ご覧のように、誤ったファイルシステム・チェックを実行すると、瞬く間にそこら中に損傷を受ける可能性があります。

リスト 17. 損傷を受けた XFS ファイルシステムの修復
[root@attic4-cent ~]# xfs_repair /dev/sdc3
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
bad magic # 0x1060000 for agf 0
bad version # 33947648 for agf 0
bad sequence # 17039360 for agf 0
bad length -143002337 for agf 0, should be 655360
flfirst 25427968 in agf 0 too large (max = 1024)
fllast -42401760 in agf 0 too large (max = 1024)
bad magic # 0x80024000 for agi 0
bad version # -2130558976 for agi 0
bad sequence # 16384 for agi 0
bad length # -25362400 for agi 0, should be 655360
reset bad agf for ag 0
reset bad agi for ag 0
freeblk count 1 != flcount 1024 in ag 0
bad agbno 33555456 for btbno root, agno 0
bad agbno 0 for btbcnt root, agno 0
bad agbno 0 for inobt root, agno 0
agi_count 1024, counted 0 in ag 0
agi unlinked bucket 0 is 8404992 in ag 0 (inode=8404992)
agi unlinked bucket 1 is 4269604896 in ag 0 (inode=4269604896)
agi unlinked bucket 2 is 1024 in ag 0 (inode=1024)
...
agi unlinked bucket 62 is 2307015680 in ag 0 (inode=2307015680)
agi unlinked bucket 63 is 2323792896 in ag 0 (inode=2323792896)
sb_icount 64, counted 0
sb_ifree 61, counted 0
sb_fdblocks 10480520, counted 9825176
root inode chunk not found
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
...
        - agno = 15
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 1
        - agno = 0
        - agno = 2
...
        - agno = 15
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

スーパーブロック

これまで説明したチェック・ツールと修復ツールが作業に取り掛かる場所をどうやって知るのか、不思議に思っている方もいることでしょう。通常、Linux と UNIX のファイルシステムにはスーパーブロックがあり、このスーパーブロックにファイルシステムのメタデータが記述されます。メタデータとは、ファイルシステムそのものの情報を表すデータのことです。メタデータは一般に既知の場所 (大抵はファイルシステムの先頭かその近く) に保管され、他の周知の場所に複製されます。既存のファイルシステムの場合、mke2fs-n オプションを指定して実行すると、スーパーブロックの場所が表示されます。ファイルシステムを作成する際に、i ノードあたりのバイト数の値などをパラメーターとして指定した場合には、そのときと同じパラメーターを、-n オプションを使用する際にも指定して mke2fs を呼び出す必要があります。リスト 18 に、/dev/sda5 でスーパーブロックが置かれている場所を示します。スーパーブロックの場所を表示する際には、そのファイルシステムがマウントされていなければならないことに注意してください。

リスト 18. スーパーブロックの場所の検索
[root@attic4-cent ~]# mke2fs -n /dev/sda5
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
4530176 inodes, 18109263 blocks
905463 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
553 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424

高度なツール

ファイルシステムの検査または修復には、さらに高度なツールをいくつか使用することができます。正しい使い方については man ページを、ハウツー情報については Linux Documentation Project (「参考文献」を参照) を調べてください。これらのコマンドでは必ずと言ってよいほど、ファイルシステムをアンマウントする必要がありますが、関数によっては読み取り専用でマウントされているファイルシステムで使用できるものもあります。以下に、高度なコマンドをいくつか抜粋して説明します。

修復を試みる前に、必ずファイルシステムをバックアップしてください。

ext2 および ext3 ファイルシステム用のツール

tune2fs
ext2 および ext3 ファイルシステムのパラメーターを調整するためのツールです。このツールを使用して、ext2 ファイルシステムにジャーナルを追加して ext3 ファイルシステムに変換したり、強制チェックが行われる前にマウントの最大数を表示、または設定したりすることができます。さらに、各種のオプション機能にラベルを割り当て、それぞれの機能を設定したり無効にしたりすることもできます。
dumpe2fs
ext2 または ext3 ファイルシステムのスーパーブロックおよびブロック・グループ記述子情報を出力します。
debugfs
対話型ファイルシステム・デバッガーです。このツールを使用して、ext2 または ext3 ファイルシステムの状態を確認、または変更することができます。

Reiserfs ファイルシステム用のツール

reiserfstune
ReiserFS ファイルシステムのパラメーターを表示、調整するためのツールです。
debugreiserfs
ReiserFS ファイルシステムに対し、dumpe2fs および debugfs と同様の関数を実行します。

XFS ファイルシステム用のツール

xfs_info
XFS ファイルシステムに関する情報を表示します。
xfs_growfs
XFS ファイルシステムを拡張します (別のパーティションが使用可能であることが前提)。
xfs_admin
XFS ファイルシステムのパラメーターを変更します。
xfs_repair
マウント・チェックではシステムを修復しきれない場合に、XFS ファイルシステムを修復します。
xfs_db
XFS ファイルシステムを検査、またはデバッグします。

Btrfs ファイルシステム用のツール

注: Btrfs の man ページをオンラインで検索する必要があるかもしれません。

btrfs
Btrfs ファイルシステム情報の数多くの側面を表示します。
btrfsck
Btrfs ファイルシステムをチェックします。
btrfs-find-root
Btrfs ファイルシステムのルート・ブロックを検索します。
btrfs-debug-tree
Btrfs の内部メタデータを表示します。
btrfstune
Btrfs ファイルシステムの各種パラメーターを調整して、一部の拡張機能を有効または無効にします。
btrfs-restore
損傷を受けた Btfrs ファイルシステムからファイルのリストアを試みます。

ツールの説明の締めくくりとして、ext 系列のファイルシステムの内部動作を調べるために使用する debugfs コマンドについて説明します。デフォルトでは、このコマンドはファイルシステムを読み取り専用モードで開きます。debugfs には多くのコマンドが用意されており、ファイルやディレクトリーのアンデリートを試行するためのコマンドや、書き込みアクセスが必要なその他の操作を行うコマンドなどがあります。したがって、-w オプションを使用して明示的に書き込みアクセスを可能にしなければならないため、このコマンドは慎重に使用する必要があります。

リスト 19 では私のシステムを例に、ルート・ファイルシステムを開き、ホーム・ディレクトリーにナビゲートし、index.html という名前のファイルに関する情報 (i ノード番号を含む) を表示し、最後に i ノード番号をファイルのパス名にマッピングする方法を示しています。debugfs では、? を指定すると、使用可能なコマンドのリストが表示されるようになります。この例では、ファイルシステムはマウントされており、検査を行っても差し支えない状態です。マウントされたファイルシステムで修復を試みてはいけません

リスト 19. debugfs を使用する
[root@attic4-cent ~]# debugfs /dev/sda11
debugfs 1.41.12 (17-May-2010)
debugfs:  cd home/ian
debugfs:  pwd
[pwd]   INODE: 3825697  PATH: /home/ian
[root]  INODE:      2  PATH: /
debugfs:  stat index.html
Inode: 3832472   Type: regular    Mode:  0664   Flags: 0x0
Generation: 301826695    Version: 0x00000000
User:  1000   Group:  1000   Size: 13430
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 32
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x55c37766 -- Thu Aug  6 11:04:06 2015
atime: 0x55c37c42 -- Thu Aug  6 11:24:50 2015
mtime: 0x55940f92 -- Wed Jul  1 12:04:34 2015
Size of extra inode fields: 4
Extended attributes stored in inode body: 
  selinux = "unconfined_u:object_r:user_home_t:s0\000" (37)
BLOCKS:
(0-1):15323651-15323652, (2):15323686, (3):15342497
TOTAL: 4

debugfs:  ncheck 3832472
Inode	Pathname
3832472	/home/ian/index.html
debugfs:  q

まとめ

このチュートリアルでは、ファイルシステムのチェック、変更、修正に使用できるさまざまなツールについて説明しました。このチュートリアルで説明したツールだけでなく、どのツールを使用する場合でも、常に十分な注意が必要であることを忘れないでください。たった 1 つのキーを間違えただけで、データが失われる可能性があるのです。

参考文献

学ぶために

  • developerWorks Premium のメンバーになると、強力なツールや Safari Books Online から集めて管理する技術ライブラリーをすべて自由に利用できるほか、カンファレンスの割引を受けることや、カンファレンスの記録を閲覧することができ、さらには SoftLayer や Bluemix を利用できるクレジットが提供されるなど、さまざまな特典があります。
  • 2015年 4月時点での LPI のバージョン 4.0 の試験項目に基づく LPIC-1 認定に備えて勉強するのに役立つ developerWorks のチュートリアルを見つけるには、developerWorks の LPIC-1 ロードマップを利用してください。
  • Linux Professional Institute の Web サイトで、LPIC の詳細な試験項目、課題のリスト、例題を調べてください。特に以下のページを参照してください。 必ず Linux Professional Institute の Web サイトで最新の項目を参照してください。
  • The Linux Documentation Project には、HOWTO 文書をはじめ、各種の有益な文書が豊富に揃っています。
  • さまざまな IBM 製品や IT 業界のトピックに焦点を絞った developerWorks テクニカル・イベントで最新の技術情報を入手してください。
  • Twitter で developerWorks をフォローしてください。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、Wiki を調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=1030810
ArticleTitle=Linux の 101 試験対策: ファイルシステムの整合性の維持
publish-date=05122016