2013年01月01日
ext3 journalメモ
Journaling the Linux ext2fs Filesystemのメモ(1)
Designing a new filesystem for Linux
クラッシュ後のリカバリ時間を短縮することが目的である。
journalingは早いリカバリが実行できる、なぜなら常に私たちは
ディスク上で不具合が発生する可能性があるすべてのデータを
journal内に記録されていることを知ることができるから
結果として、journalをスキャンして、すべてのコミットされたデータを
main FS領域にコピーしもどすことでFSリカバリが実施される。
journalはFSよりもずっと小さいのでとても早く完了する
Journalingは別の利点もある。journaling FSは短期間のデータを新しい場所(
ディスク上の独立した永続したデータ、メタデータ)に保持するという点で従来のFSとは異なる。
これによって、FSは永続したデータを特定の方法で格納することを命令しないので、
ext2などはディスク上のフォーマットを変更することなく、journalingバージョンとして
利用することが可能となる。
Anatomy of a transaction
jouranled FSのもっともなコンセプトはFSの単一更新に相当する"transaction"である。
1つのtransactionはアプリからのリクエストにより単一FSから作成される結果であり、
それ(transaction)はリクエストからのすべてのメタデータ変更の結果を含む。
例えばファイルへのwriteはディスク上のinodeのtimestampとwriteによりファイルが
拡張される場合は、block mapping情報の更新となる。quota情報(空きブロック、未使用
bitmap)も新しくブロックが割り当てられたら更新され、それらすべてはtransactionに
記録される。
transactionには私たちが気づかなければならない隠れた他のオペレーションがある。
transactionはまたFSに存在する内容を読み込み、transaction間で整頓するということだ。
ディスク上のブロックを修正したtransactionは新しいデータを読み、
何を読んだかに基づきディスクを更新するtransactionの後はコミットできない。
2つのtransactionが同じブロックを書き戻さない場合においてさえ、依存関係は存在する:
想像してください、ディレクトリのとあるブロックからfilenameを消しているtransactionがあり、
もう一方のtransactionが他のブロックに同じfilenameを追加しようとしている。
2つのオペレーションはそれらが書くブロックを重複していないかもしれないが、
2つ目のオペーレーションは最初のが成功したときだけ、有効となる(これに違反すると
重複したディレクトリエントリとなる)
Merging transactions
jouranled FSではjournalingは複雑なtransactionからatomicなcommitを保証する
標準的なメカニズムである、databaseの世界からくるたくさんの専門用語とテクノロジーが利用されている.
Designing a new filesystem for Linux
クラッシュ後のリカバリ時間を短縮することが目的である。
journalingは早いリカバリが実行できる、なぜなら常に私たちは
ディスク上で不具合が発生する可能性があるすべてのデータを
journal内に記録されていることを知ることができるから
結果として、journalをスキャンして、すべてのコミットされたデータを
main FS領域にコピーしもどすことでFSリカバリが実施される。
journalはFSよりもずっと小さいのでとても早く完了する
Journalingは別の利点もある。journaling FSは短期間のデータを新しい場所(
ディスク上の独立した永続したデータ、メタデータ)に保持するという点で従来のFSとは異なる。
これによって、FSは永続したデータを特定の方法で格納することを命令しないので、
ext2などはディスク上のフォーマットを変更することなく、journalingバージョンとして
利用することが可能となる。
Anatomy of a transaction
jouranled FSのもっともなコンセプトはFSの単一更新に相当する"transaction"である。
1つのtransactionはアプリからのリクエストにより単一FSから作成される結果であり、
それ(transaction)はリクエストからのすべてのメタデータ変更の結果を含む。
例えばファイルへのwriteはディスク上のinodeのtimestampとwriteによりファイルが
拡張される場合は、block mapping情報の更新となる。quota情報(空きブロック、未使用
bitmap)も新しくブロックが割り当てられたら更新され、それらすべてはtransactionに
記録される。
transactionには私たちが気づかなければならない隠れた他のオペレーションがある。
transactionはまたFSに存在する内容を読み込み、transaction間で整頓するということだ。
ディスク上のブロックを修正したtransactionは新しいデータを読み、
何を読んだかに基づきディスクを更新するtransactionの後はコミットできない。
2つのtransactionが同じブロックを書き戻さない場合においてさえ、依存関係は存在する:
想像してください、ディレクトリのとあるブロックからfilenameを消しているtransactionがあり、
もう一方のtransactionが他のブロックに同じfilenameを追加しようとしている。
2つのオペレーションはそれらが書くブロックを重複していないかもしれないが、
2つ目のオペーレーションは最初のが成功したときだけ、有効となる(これに違反すると
重複したディレクトリエントリとなる)
Merging transactions
jouranled FSではjournalingは複雑なtransactionからatomicなcommitを保証する
標準的なメカニズムである、databaseの世界からくるたくさんの専門用語とテクノロジーが利用されている.
【Linuxの最新記事】
2012年05月02日
systemtapのテンプレートkernelをデバッグするときにsystemtapを利用するのですが、
毎回スクリプトを作るのが面倒くさいのでテンプレートを作成するのを書いてみました(使う場合は、末尾のスクリプトをコピペしてください)。 個人的なスクリプトなので自己責任で利用してください。 使い方は ”./stap-setter.sh [mh] 関数 ” です。 例えば ext4_fill_superが実行されたことを出力したい場合、 ./stap-setter.sh ext4_fill_super と実行します。すると"test.stp"が下記の内容でできあがります。
# stap test.stp でsystemtapを実行します。 裏でext4をmountするとext4_fill_superが呼ばれるので start ext4_fill_super called と出力されます。 printfで関数の呼び出しだけ出力しているのですが、print_backtrace()に置き換えて バックトレースを見たりもできます。 そこら辺はsystemtapのマニュアルに書いてありますので、別の機会に。 モジュールの場合は -m をつけます。ext3/ext4/jbd/jbd2しか対応してませんが、 他のモジュールも利用する場合は、スクリプト内の配列に追加すればokです。
2012年02月11日
bigalloc (1)linux-3.2でkernelにマージされたbigallocについて
デフォルトでは有効にならないため、"-O bigalloc"でext4のbigallocが有効になる(e2fsprogsはcommit: c6ed60cdeb1 以降。その後バグ修正も色々入っているので最新のを利用したほうがよい)。 また、-C でcluster(ブロックの集まり)のサイズを指定できる。デフォルトは16K(4KB*16)。 # ./mke2fs -t ext4 -O bigalloc /dev/sda8 mke2fs 1.42 (29-Nov-2011) Filesystem label= OS type: Linux Block size=4096 (log=2) Cluster size=65536 (log=6) Stride=0 blocks, Stripe width=0 blocks 129664 inodes, 2074112 blocks 103705 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=2147483648 4 block groups 524288 blocks per group, 32768 clusters per group 32416 inodes per group Superblock backups stored on blocks: 524288, 1572864 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done debugfsでbigallocが設定されていることを確認 # ./debugfs -R stats /dev/sda8 debugfs 1.42 (29-Nov-2011) Filesystem volume name: Last mounted on: Filesystem UUID: 5c8b5f8e-5059-4215-aa8e-24a930c8ce92 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 bigalloc Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 129664 Block count: 2074112 Reserved block count: 103705 Free blocks: 2033024 Free inodes: 129653 First block: 0 Block size: 4096 Cluster size: 65536 Reserved GDT blocks: 31 Blocks per group: 524288 Clusters per group: 32768 Inodes per group: 32416 Inode blocks per group: 2026 Flex block group size: 16 Filesystem created: Sat Feb 11 22:28:11 2012 Last mount time: n/a Last write time: Sat Feb 11 22:28:11 2012 Mount count: 0 Maximum mount count: -1 Last checked: Sat Feb 11 22:28:11 2012 Check interval: 0 ( Lifetime writes: 128 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: f7ac2cd7-ee6a-43d2-b8ef-de2533eb8008 Journal backup: inode blocks Directories: 2 Group 0: block bitmap at 33, inode bitmap at 49, inode table at 65 32254 free clusters, 32405 free inodes, 2 used directories, 32405 unused inodes ... bigallocの詳細はまた今度
2011年08月20日
bash条件式bashの条件式についてのメモ
e.g. if [ &VAL -a file ]
2011年07月13日
ext4 secure deleteext4のSecure Deleteについて紹介します。
2011/7/13現在(linux-3.0-rc7)、 まだメーリングリスト上で議論中なのでメインラインへはマージされていません。 この機能はext4の拡張属性に"s"を追加(chattr +s)して、 それが設定されているファイルを削除するときは、 カーネル空間では0でデータをクリアしてあげましょうというものです。 なぜそんなことをしているかというとext4はデータを削除するときにメタデータだけを クリアしており、実物のデータはそのままであるためです。 なので、うまいことハッキングすれば削除したはずのデータが読み出せてしまいます。 データを削除するときにメタデータだけを更新するほうがデータ量が少なくて パフォーマンスが良いです。 つまり、この機能はトレードオフでセキュリティを重視したいファイルなどだけに設定し、 実際の削除が遅くなるのは目をつぶるという感じです。 下記のパッチがリリースされています。 EXT4: Secure Delete: Zero out files directory entry 0/2 [PATCH 0/2 v3] EXT4: Secure Delete http://www.spinics.net/lists/linux-ext4/msg26365.html 1/2 [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data http://www.spinics.net/lists/linux-ext4/msg26364.html inodeにEXT4_SECRM_FLが設定されていた場合、 カーネル内部のフラグEXT4_FREE_BLOCKS_ZEROを設定し、 ブロック解放処理でそのフラグの有無を判定し対象となるブロックに0で書き込みます。 EXT4_FREE_BLOCKS_ZEROが設定されていない場合は、通常のブロック開放(メタデータのみ更新)を 行います。 2/2 [PATCH 2/2 v3] EXT4: Secure Delete: Zero out files directory entry http://www.spinics.net/lists/linux-ext4/msg26366.html 2つ目はディレクトリエントリに対する0うめ処理部です。 inodeに EXT4_SECRM_FLが設定されていた場合、 ディレクトリエントリに内部のflag EXT4_DEL_ENTRY_ZEROを設定します。 EXT4_DEL_ENTRY_ZEROが設定されていたら dnetryのnameを0でうめ、そのdentryを保持するblockをディスクへ書き出します。 flagが設定されていない場合は従来のディレクトリエントリの削除処理をします。 ここで0クリアするのはnameとfile_typeのみです。 ディレクトリエントリの構造体は下記のとおりなのですが、 このパッチではinode番号を消してないのですが、別にいいのだろうか。 dentry2構造体ごと0うめすればいいと思うけど、もしかしたらI/Oの発行を抑えるために重要そうな エントリだけけしているのかもしれない。 struct ext4_dir_entry_2 { __le32 inode; /* Inode number */ __le16 rec_len; /* Directory entry length */ __u8 name_len; /* Name length */ __u8 file_type; char name[EXT4_NAME_LEN]; /* File name */ }; まだ議論中なのですが、方向性に問題はなさそうなので近いうちに実装されるでしょう。 他のファイルシステムの実装はよくわからないのだけれど、ext以外はすでにこのような データ消し方はできているのだろうか。 とりあえず、パーソナルユースではこの機能にお世話になることはなさそうです。 2011年04月25日
iozone (2)iozoneのオプションです。
# ./iozone -h で表示されます。 -a フル自動モード。すべてのオペレーションのテストを実施する。 レコードサイズは4Kから16Mファイルサイズは64Kから512M -A より多くの範囲を評価するモード、ただし時間がかかる。 -aはファイルサイズが32MBより大きい場合、転送速度が64Kより小さいと自動的にとまるが、 このモードでは止まらない。 -b filename 結果のファイル名を指定 -B 測定用の一時的なファイルの作成、読み込にmmap()インターフェースを利用する。 -c タイミングの計算にcloseを含ませる -C throughputテストで子プロセスの転送バイト数を表示する。 -d # バリアのマイクロ秒の遅延を許可する -D mmapファイルでmsyncを利用する。すべてのデータはディスクへ非同期になる -e タイミングの計算にfsync,fflushを含む -E 拡張テストを選択するために利用する。特定のプラットフォームでのみ利用可能。 -f filename テスト中の一時ファイルの名前を指定する。 -F filename filename filename … throughputテストでの一時ファイル名を指定する。 -g # autoモードでの最大ファイルサイズ(KB) -G mmapファイルでmsyncを利用する。すべてのデータはディスクへ同期される -h ヘルプを表示する -H # POSIX async I/Oでasyncオペレーションを利用する -i # 指定したテストを実行する (0=write/rewrite, 1=read/re-read, 2=random-read/write 3=Read-backwards, 4=Re-write-record, 5=stride-read, 6=fwrite/re-fwrite, 7=fread/Re-fread, 8=random mix, 9=pwrite/Re-pwrite, 10=pread/Re-pread, 11=pwritev/Re-pwritev, 12=preadv/Re-preadv). -I VXFSファイルシステムでVX_DIRECTをすべてのファイルオペレーションを利用する -j # ファイルアクセスのstrideサイズ設定する -J # I/O操作のまえにミリ秒の遅延の計算を実行する -k # POSIX async I/O (no bcopy)でasyncオペレーションを利用する -K 通常のテスト中にランダムアクセスする -l # 実行するプロセスの最小数を指定する -L # プロセッサーキャッシュラインのサイズ(byte)を指定する -m 複数の内部バッファを利用する -M アウトプットファイルにuname()を出力する -n # autoモードでの最小ファイルサイズ(byte)を設定する -N オペレーションごとにマイク秒の結果を出力する -o 同期書き込みをする(O_SYNC) -O ops/secで結果を出力する -p ファイルオペレーションの前にプロセッサキャッシュを破棄する -P # プロセスとスレッドをcpu #に固定する -q # 最大レコードサイズ(Kbyte)を設定する -Q offset/latencyファイルを作成する -r # レコードサイズをKbyteで指定する -R 出力をエクセル形式にする -s # テストとのファイルサイズを指定する(k = Kbytes, m = Mbytes, g = Gbytes) -S # プロセッサーキャッシュサイズを設定する(Kbyte) -t # throughputモードでIozoneを実行する -T throuputテストでPOSIX pthreadを利用する -u # 実行するプロセッサの上限を設定する -U mountpoint マウントポイントを指定する -v Iozoneのバージョンを表示する -V # 読み書きでのデータ確認 -w 使い終わった一時ファイルを削除しない -W ファイルの読み書きでファイルをロックする -x throughputテストで利用されるstone-walling機能を無効にする。 -X filename write telemetry information -y # 最小レコードサイズ(Kbyte) -Y filename read telemetry information -z -aと一緒に使われ小さいrecord sizeを含ませる -Z mmapとfileのI/Oをミックスする -+m filename clusterテストでクライアントの設定情報を取得するために利用する -+n 再テストしない -+N シーケンシャル書き込みテストで前に作ったファイルのトランケートと削除をしない -+u CPU utilizationモードを有効にする -+d 診断モードを有効にする -+p percent_read ランダムreadテストでのスレッド/プロセスの割合を設定する -+r すべてのI/OテストでO_RSYNC,O_SYNCを有効にする -+t ネットワーク性能測定を有効にする。-+mが必要 -+A madviseを有効にする 0 = normal, 1=random, 2=sequential, 3=dontneed, 4=willneed. iozone(1) 2011年04月20日
debugfs (1) (ext4)e2fsprogsパッケージに含まれるdebugfsコマンドの出力について説明します。
e2fsprogs 1.41.14 (22-Dec-2010) debugfsコマンドext2, ext3, ext4のほぼ全ての情報をみることができます。 また、debugと名前がついてることからもFSのメタデータの変更も可能です。 使い方は↓です。 # debugfs DEVICE debugfsコマンドは対話式に実行しますが、引数で-Rを指定する事で 任意のコマンドを実行する事が出来ます。 ここではsuper blockの情報を表示する show_super_stats (stats) の 出力について説明します。 たくさん情報が出力されますが、どれも重要なものばかりです。 ディスク上から読み取りますので、 データ変更後はsyncをしてから実行しないと 最新の情報は表示されないので注意が必要です。 [root@localhost /]# debugfs -R stats /dev/sda4 debugfs 1.41.14 (22-Dec-2010) //debugfsのバージョンと作成日 Filesystem volume name: //FSのラベル名 Last mounted on: //最後にマウントした場所を記録される。FSは作りたてなのでnot availableとなる。 ext4でファイルを開くとext4_file_openでs_last_mountedに記録される Filesystem UUID: 63bf5472-6f19-4154-b969-eeb39b8a1643 //FSのUUID Filesystem magic number: 0xEF53 //FSのマジック番号、ext2,ext3,ext4は同じ。 Filesystem revision #: 1 (dynamic) //FSのリビジョンレベル。dynamic inode sizeをサポートする場合は1 Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_su per large_file huge_file uninit_bg dir_nlink extra_isize //FSがサポートする機能フラグ。詳細はまた別途。 Filesystem flags: signed_directory_hash //ディレクトリハッシュのタイプ。unsigned or signed Default mount options: user_xattr acl //デフォルトのマウントオプション Filesystem state: clean //FSのステータス。clean or error or orphan Errors behavior: Continue //エラー検出時の振る舞い。continue or ro mount or panic Filesystem OS type: Linux // OSの型 Inode count: 183264 // FSのinode数 Block count: 732421 // FSのブロック数 Reserved block count: 36621 // FSの中でroot用に予約されているブロック数 Free blocks: 703451 //利用可能なブロック数 Free inodes: 183253 //利用可能なinode数 First block: 0 //先頭の物理ブロック番号 Block size: 4096 //FSのブロックサイズ Fragment size: 4096 //フラグメントサイズ。未使用 Reserved GDT blocks: 178 //オンラインリサイズ(拡張)のための予約ブロック数 Blocks per group: 32768 //ブロックグループあたりのブロック数 Fragments per group: 32768 //ブロックグループあたりのframent数(使われない) Inodes per group: 7968 //ブロックグループあたりのinode数 Inode blocks per group: 498 //ブロックグループあたりのinodeブロック数 Flex block group size: 16 //flex bgの大きさ Filesystem created: Sun Apr 3 21:46:16 2011 //FSが作成された時間 Last mount time: Wed Apr 6 20:11:45 2011 //最後にマウントした時間 Last write time: Wed Apr 6 20:11:45 2011 //最後に書き込まれた時間 Mount count: 1 //マウントとした回数 Maximum mount count: 20 //fsckを実行するまでのマウント回数 Last checked: Sun Apr 3 21:46:16 2011 //最後にfsckを実行した時間 Check interval: 0 ( //fsckの間隔。0は実行しない。 Lifetime writes: 110 MB //今まで書き込まれたデータ量 Reserved blocks uid: 0 (user root) //予約領域を利用出来るdefaultのユーザー番号 Reserved blocks gid: 0 (group root) //予約領域を利用出来るdefaultのグループ番号 First inode: 11 //FSで利用出来る最初のinode番号 Inode size: 256 //inode size (byte) Required extra isize: 28 //最小のinode使用サイズ (byte) 2011年04月20日
filefrage2fsprogsに含まれる、filefragコマンドについて説明します。
filefragコマンドはファイルのフラグメント等を表示するコマンドです。 ユーザー空間からFS_IOC_FIEMAP ioctlをつかって、ディスクからファイルのエクステントの数を取得し、表示します。 FIEMAPはext4固有ではなく、VFS層のioctlであるため、色々なファイルシステムに対して 実行出来ます。例えばxfsでもFS_IOC_FIEMAPをサポートしています。 エクステント数はフラグメント数と等しい為、その数を数えることでファイルの フラグメントを知ることができます。 下記は実行例です。-vオプションをつけることで詳細な情報を得られます。 [root@linux mnt]# filefrag -v /mnt/mp1/file1 Filesystem type is: ef53 File size of /mnt/mp1/file1 is 31457280 (7680 blocks, blocksize 4096) ext logical physical expected length flags 0 0 34816 7680 eof /mnt/mp1/file1: 1 extent found 出力されている情報は下記のものです。 Filesystem type ファイルシステムのマジック番号です。ext2/3/4共通です ext エクステントの番号を示します。0から数えます。 logical 論理ブロック番号(ファイル相対のブロック番号)です。 physical 物理番号 (ファイルシステム相対のブロック番号)です。 length ブロック長です。 flags 最後のextentや未初期化extentなどのステータスを示します manualをみると-vオプションのみ記載されていますが、 ソースコードをみると下記のオプションも実装されています。 マニュアルはそのうち更新されるでしょう B force_bitmap indirect block管理で情報を表示する b ファイルのブロックサイズではなく、1K blocksizeで表現する s syncしてから情報を取得する(ディスク上の最新の情報をとってくる) x 拡張属性のマッピングを取得する 以前はdebugfsコマンドでファイルの物理ブロック番号等を取得していましたが、 こちらの方が手軽でかつ柔軟な利用が可能です。 ファイルの読み込みが遅いと感じた場合はfilefragコマンドを利用し、 フラグメントの状態を確認してみると良いかもしれません。 2011年04月17日
e2undoe2undoコマンドの使い方について説明します(kenrel: 2.6.39-rc1 e2fsprogs: 1.41.12)。
e2fsprogsパッケージに含まれており、ext2/ext3/ext4に対して実行できます。 e2undoコマンドは実行したコマンドをlogからリプレイします。 今回はtune2fsコマンドでのinodeサイズの変更を取り消す方法を例とします。 inodeサイズはmke2fsコマンドでFSを作成する際に指定出来ます。 通常、ext2/ext3では128byteで管理されます。 一方、ext4は256byteがデフォルトとなっています。 ext4ではnano秒単位で時間を保持出来る様になっており、その情報がinode内に格納する 関係で128byteより大きな値になっています。 また32bitで管理するその他エントリの拡張にも利用されます。 それ以外のinodeの余り領域には、ACLや拡張属性(xattr)の情報が格納されます。 128byte時は外部に取得したブロックにこれらの情報が格納されます。 そのため、inode内部に保持した方が、inode外のブロック読み込みが発生しないため 若干のアクセス性能の向上が見込めます。 ただ、体感として違いがわかるには大量のアクセスが必要となります。 ext2/ext3でも128byteより大きなinodeサイズを指定出来ますが、 ACL, xattrを使わない限りメリットはありません。 むしろ、inodeが小さい方がファイルの作成時間が短くてすみますので、 ext2/ext3ではinodeサイズは128byteで運用すべきだと思います。 1.ログの出力先を作成する まずはログファイルの出力先として、/var/lib/e2fsprogsを作成します。 [root@localhost /]# mkdir -p /var/lib/e2fsprogs 2. ext4の作成 ext4をinodeサイズ128byteで作成します。 e2fsprogs: 1.41.12のtune2fsではflex_bgが有効である場合、 inodeサイズの変更をサポートしていないため、flex_bgをoffにします(将来的にはサポートされるようになるかもしれません)。 [root@localhost /]# mkfs -t ext4 -I 128 -O ^flex_bg /dev/sda8 inodeサイズが128byteで出来ていることが確認できます。 [root@localhost /]# debugfs -R stats /dev/sda8 debugfs 1.41.14 (22-Dec-2010) Filesystem volume name: Inode size: 128 3. inodeサイズを256byteにする tune2fsコマンドでinodeサイズを変更します。 e2undo用のログファイルが作成された旨が出力されます。 ※出力先のディレクトリがない場合は出力されません [root@localhost /]# tune2fs -I 256 /dev/sda8 tune2fs 1.41.14 (22-Dec-2010) To undo the tune2fs operation please run the command e2undo /var/lib/e2fsprogs/tune2fs-sda8.e2undo /dev/sda8 [root@localhost /]# debugfs -R stats /dev/sda8 debugfs 1.41.14 (22-Dec-2010) Filesystem volume name: Inode size: 256 4. e2undoでもとに戻す e2undoコマンドにログを指定し、inodeサイズをもとに戻します。 [root@localhost /]# e2undo /var/lib/e2fsprogs/tune2fs-sda8.e2undo /dev/sda8 | more Replayed transaction of size 1024 at location 919673 Replayed transaction of size 1024 at location 919563 Replayed transaction of size 1024 at location 919518 Replayed transaction of size 1024 at location 919449 Replayed transaction of size 1024 at location 919339 ... e2undoでリプレイした結果inodeサイズが128byteにもどっています。 [root@localhost /]# debugfs -R stats /dev/sda8 debugfs 1.41.14 (22-Dec-2010) Filesystem volume name: Inode size: 128 余談ですが、一度大きく拡張したinodeサイズは通常元に戻せません。 e2undoを実行できるログがあるときのみできます。 そのため、inodeサイズを変更する際には万が一のためにログを出力出来るようにしておくべきです。 [root@localhost /]# tune2fs -I 128 /dev/sda8 tune2fs 1.41.14 (22-Dec-2010) Shrinking the inode size is not supported 2011年04月16日
犬のトリマー久しぶりに犬の毛を切ってもらいにいきました。 行こうと思っていた矢先に震災があり、しばらくお店がやってなかったのでやっと切りにいけました。 Before おまかせだったのですが、大分こざっぱりしてきました。 After メスです。
>>次へ
×
この広告は30日以上新しい記事の更新がないブログに表示されております。 |