ext4が出始めの頃、アクセスの仕方をしらべたんだけど、その後進展があったようだ。
windowsからext2系ファイルシステムへのアクセスをするのにはext2fsdが一番だと思う。
が、ext4はなかなか色々と拡張がなされていて、特にextentsオプションが指定されたext4ファイルシステムは読み込みさえできなかった。
んだけど、いつの間にやらとりあえず読み込みに関してはサポートされたようだ。
1, Ext4 extent readonly support by Bo Branten. Writing is possible but with no size-extending
ファイルサイズを拡大しない書き込みなら一応書き込みもできるらしい。
まあ、危ないから書き込みはやめておいた方が無難ですな。
ext2fsdの最新バージョンは0.51で0.50からext4のextentsオプション付きの読み込みに対応したようだ。
もちろんWindows7でも使える。
更新履歴を見るとがんばってext4対応を進めているようだ。
どうしてもLinuxのファイルシステムをWindowsから読み書きを今すぐ自由にしたいなら、とりあえずext3を使うかext4をextentsオプション抜きで利用するかかなあ。
extents付きのext4の読み込みサポートまでおよそ1年半か。
書き込みサポートも気長に待たないとだめっぽいですな。
うちのサーバ機はxenを使って仮想化して運用している。
そして毎日定期バックアップをLVMのスナップショット機能を利用して行っているのだけども、どうも最近挙動がおかしいことに気づいた。
作成したスナップショットが高確率でファイルシステムにエラーを含んでいる。
# xm pause debian # lvcreate -s -n snapdebian -L 200G /dev/ms09/debian Logical volume "snapdebian" created # xm unpause debian
としてスナップショットを作成する。
ここまではいい。
が、ここでfsckを走らせるとエラーが出る。
# e2fsck -yfv /dev/ms09/snapdebian e2fsck 1.41.12 (17-May-2010) /dev/ms09/snapdebian: recovering journal Clearing orphaned inode 15466504 (uid=109, gid=109, mode=0100600, size=0) Clearing orphaned inode 15466503 (uid=109, gid=109, mode=0100600, size=0) Clearing orphaned inode 15466502 (uid=109, gid=109, mode=0100600, size=0) Clearing orphaned inode 15466501 (uid=109, gid=109, mode=0100600, size=20) Clearing orphaned inode 15466500 (uid=109, gid=109, mode=0100600, size=0) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/ms09/snapdebian: ***** FILE SYSTEM WAS MODIFIED ***** 715619 inodes used (2.13%) 738 non-contiguous files (0.1%) 182 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 706955/133 23572155 blocks used (17.56%) 0 bad blocks 6 large files 677160 regular files 29784 directories 126 character device files 40 block device files 2 fifos 16 links 8469 symbolic links (8324 fast symbolic links) 29 sockets -------- 715626 files
マウントしてrsyncでバックアップをとるとumountでえらい時間がかかる。
カーネルが文句いってる。
[ 647.099517] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466504 [ 647.099539] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466503 [ 647.099548] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466502 [ 647.099556] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466501 [ 647.099591] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466500 [ 647.099599] EXT4-fs (dm-18): 5 orphan inodes deleted [ 647.099710] EXT4-fs (dm-18): recovery complete [ 647.433114] EXT4-fs (dm-18): mounted filesystem with ordered data mode [ 1080.113046] INFO: task umount:4061 blocked for more than 120 seconds. [ 1080.113114] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1080.113201] umount D 0000000000000000 0 4061 2294 0x00000000 [ 1080.113331] ffffffff8147b1f0 0000000000000282 0000000000000000 ffff8801e6971de8 [ 1080.113544] 0000000000000000 0000000000000000 000000000000f9e0 ffff8801e6971fd8 [ 1080.117004] 0000000000015780 0000000000015780 ffff8801c17654c0 ffff8801c17657b8 [ 1080.117004] Call Trace: [ 1080.117004] [<ffffffff8100e629>] ? xen_force_evtchn_callback+0x9/0xa [ 1080.117004] [<ffffffff8100ece2>] ? check_events+0x12/0x20 [ 1080.117004] [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe [ 1080.117004] [<ffffffff81109274>] ? bdi_sched_wait+0x9/0xe [ 1080.117004] [<ffffffff8130d19a>] ? _spin_unlock_irqrestore+0xd/0xe [ 1080.117004] [<ffffffff8130c3e7>] ? __wait_on_bit+0x41/0x70 [ 1080.117004] [<ffffffff8100f0ac>] ? xen_smp_send_reschedule+0x0/0x7 [ 1080.117004] [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe [ 1080.117004] [<ffffffff8130c481>] ? out_of_line_wait_on_bit+0x6b/0x77 [ 1080.117004] [<ffffffff81065f24>] ? wake_bit_function+0x0/0x23 [ 1080.117004] [<ffffffff811092ec>] ? sync_inodes_sb+0x73/0x12a [ 1080.117004] [<ffffffff8110cea1>] ? __sync_filesystem+0x4b/0x70 [ 1080.117004] [<ffffffff810f1aa2>] ? generic_shutdown_super+0x21/0xfa [ 1080.117004] [<ffffffff8100eccf>] ? xen_restore_fl_direct_end+0x0/0x1 [ 1080.117004] [<ffffffff810f1b9d>] ? kill_block_super+0x22/0x3a [ 1080.117004] [<ffffffff810f226d>] ? deactivate_super+0x60/0x77 [ 1080.117004] [<ffffffff81104bc0>] ? sys_umount+0x2dc/0x30b [ 1080.117004] [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b
場合によってはこのままumountできずにプロセスが残り続けて死ねる。
とりあえずディスクI/Oがロックされた状態になるんだろう。
この問題は稼働中のext4ファイルシステムのスナップショットを作成した際に起きるようだ。
おそらくジャーナルに書き出したデータが実データに反映されていないような状況でスナップショットを作成した場合に起きるんじゃないかと予測している。
のでext3でも同じ現象が起きるだろう。たぶん。
まあ、別にそれでも変更差分をきちんと吸収してくれているならかまわないんだけども、使い終わったスナップショットをアンマウントするのになんで何分もかかるのかがわからない。
その上、使用済みのスナップショットボリュームを削除しようとしても失敗することがある。
# lvremove -f /dev/ms09/snapdebian Unable to deactivate open ms09-debian-real (254:5) Failed to resume debian.
これに関してはバグレポートが見つかった。
とりあえず4ヶ月経過しても治っていないらしい。
んーむ。
こうなるとバックアップ手法を見直す必要性が出てくる。
Dom0とDomUとで疑似遠隔rsyncでバックアップとなるのだろうか。
だけどそれだとrootでのリモートログインが必要となるから駄目だな。
ゲストはゲストでバックアップパーティションをディスクとしてアタッチして、各自でバックアップしてもらうような形ならいけるか。
あー、設定するのがめんどくさい。
てっきり書いてたものかと思ったけど書いてなかったから書いておく。
ネタもとはkernel.orgのExt4 Howto。
まず、ext2からext3へはこう。
# tune2fs -j /dev/DEVext3からext4はこう。
# tune2fs -O extents,uninit_bg,dir_index /dev/DEVこの時点でext3でのマウントはできなくなる。
ext4のフィーチャーを有効にしたら、fsckを走らせること。
# e2fsck -fDC0 /dev/DEVまあ要するに、ext3はext2にジャーナルがついたようなもんで、ext4はext3に特定のフィーチャーがついたようなもんだと。
カーネルのバージョンによっては拡張オプションを指定しないといけない。
# tune2fs -E test_fs /dev/DEV
マウントするときのファイルシステムの形式はext4dev。
ext4ファイルシステムが開発途中だったころのカーネルバージョンでのことなので、最近はまあ平気だろうけど。
ちなみにtune2fs -lやdumpe2fsでそのパーティションについているフィーチャーを確認できる。
ファイルサーバのHDDが死にかけたので再セットアップ。
lvmでパーティションきりきり。
で、ファイルシステム作成。
# mkfs.ext3 /dev/fileserver/fssystem # mkswap /dev/fileserver/fsswap # mkfs.ext4 /dev/fileserver/file
ベースシステムのセットアップ。
# mount /dev/fileserver/fssystem /mnt/temp # debootstrap --arch=amd64 lenny /mnt/temp http://ftp.jp.debian.org/debian
いろいろと書き換え
fstabの設定 # cd temp # vi etc/fstab # /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 /dev/xvda1 none swap sw 0 0 /dev/xvda2 / ext3 errors=remount-ro 0 1 /dev/xvda3 /fileserver ext4 defaults 0 0 ホスト名の設定 # vi etc/hostname files hostsの設定 # vi etc/hosts 127.0.0.1 localhost 192.168.1.x files.waterblue.net files nicの設定 # vi etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.1.x network 192.168.1.0 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 ネームサーバの設定 # vi etc/resolv.conf nameserver 192.168.1.x aptの設定 # vi etc/apt/sources.list deb http://security.debian.org/ lenny/updates main contrib non-free deb http://ftp.jp.debian.org/debian lenny main contrib non-free シリアルコンソールの設定 hvc0を使うようにしてttyは起動しない # vi etc/inittab 1:2345:respawn:/sbin/getty 38400 hvc0 #1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2 #3:23:respawn:/sbin/getty 38400 tty3 #4:23:respawn:/sbin/getty 38400 tty4 #5:23:respawn:/sbin/getty 38400 tty5 #6:23:respawn:/sbin/getty 38400 tty6 # vi etc/securetty hvc0 hvc0の作成 # cd dev # mknod hvc0 c 229 0
xenのDomU用設定ファイルを作る。
# # Configuration file for the Xen instance file, created # by xen-tools 3.9 on Sun Oct 11 14:47:01 2009. # # # Kernel + memory size # kernel = '/boot/vmlinuz-2.6.32-5-xen-amd64' ramdisk = '/boot/initrd.img-2.6.32-2-xen-amd64' memory = '512' # # Disk device(s). # root = '/dev/xvda2 ro' disk = [ 'phy:/dev/fileserver/fsswap,xvda1,w', 'phy:/dev/fileserver/fssystem,xvda2,w', 'phy:/dev/fileserver/file,xvda3,w', ] # # Hostname # name = 'file' # # Networking # vif = [ 'ip=192.168.1.x,mac=xx:xx:xx:xx:xx:xx' ] # # Behaviour # on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart'
あとは/mnt/tempをアンマウントしてxm create file -cで起動してコンソールログインしてお好きに。
ちなみに、ext4ファイルシステムはカーネル2.6.26だと
# tune2fs -E test_fs /dev/fileserver/file
やってからext4devじゃないとマウントできなかった。
2.6.32だとext4じゃないとマウントできなかった。
ext3とext4って何が変わったのかようしらんかったのでついでに違いを調べてみた。
- ファイルシステムの最大サイズが16TBから1EB（1,048,576 TB）に
- ファイルの最大サイズが2TBから16TBに
- 最大サブディレクトリ数が32000から無制限に
- ファイルのデータへの参照方法が間接ブロックマッピングからエクステントに（前のエントリの下のほう参照）
- ファイルシステムへのデータの配置時、ブロックアロケータが1ブロックずつではなくたくさんのブロックに配置できるように（マルチブロックアロケーション）
- 遅延配置ができるように（ディレイドアロケーション）
- fsckが2から20倍の早さに
- ジャーナルにチェックサムつけるようになって信頼性向上
- ジャーナルを使わないモードも指定できる
- オンラインデフラグが可能に（未実装）
- inodeのデフォルトが256バイトになってナノ秒まで保持するように
- 持続的な事前配置が可能に（persistant preallocation）
- barriersオプション（RDBMSでbegin transaction, commit transactionとかやるようなもん）がデフォルトに
まあそんな感じらしい。
でまあ、ちょっとext4特有のフィーチャーに関して調べてみた。
- extent — 4にあたる。でかいファイルへの読み書きが速くなる予定。フラグメンテーションも軽減。
- huge_file — 1,2にあたる。たぶん。一般ユーザには関係なさそう。
- dir_nlink — 3にあたる。企業システムとかだとたまにこれはまるんだよね。
- extra_isize — 11にあたる。タイムスタンプがナノ秒まで見られてもありがたみがあまりよくわからないが、inodeが256バイトないとext4の固有の機能が使えないぽい。たぶんextentsとかblock group周りで使いそう。あとまあ、でかいファイルだと間接参照が減るんで、extents使わなくても大容量ファイルの取り扱いは早くなる。んじゃないかな。昔はinodeの枯渇とかありましたね。
- flex_bg — ブロックグループのinodeとbitmapの配置位置が自由になる。これにより仮想的な大きなブロックグループを使ってinodeの割り当てをする。速度向上やフラグメンテーション軽減。
- uninit_bg — 7にあたる。ブロックグループのデータブロックビットマップとiノードビットマップを初期化しないでアクセスする。使用されていないinodeのリストをそれぞれのブロックのiノードテーブルの最後にチェックサムをつけて保持しておいて、e2fsckのときに読むなよフラグをグループディスクリプタにくっつける。結果inodeの数が多ければ多いほどfsckにかかる時間が相対的に短くなる。
で、マウントオプション。
- journal_checksum — 8にあたる。
- noload — ジャーナルをロードしない。9にあたる。
- barrier — 13。デフォルト。無効にするならnobarrierまたはbarrier=0。
- orlov — 5。デフォルト。マルチブロックアロケータを使う。ext3までのがいいならoldalloc。
- delalloc — 6。デフォルト。キャッシュから実際に書き出されるまでアロケーションを遅らせる。flex_bgやextentsが有効だと相乗効果でその間に配置の最適化とかが進んでより速く。キャッシュに入ったらすぐブロック確保したいならnodelalloc。
なんか12はext3でも実装されてるような。
マウントオプションはリストにあがってないやつは省き。
こうしてみてみるとext4ってよさそうな。
でもWindowsでマウントできないのはいやだなー。
extent, dir_nlink, extra_isize, flex_bg, uninit_bgってかんじかなー。
huge_fileはどっちでも。
基本的にLinuxのディストリはDebian信者なんですが、Debian派生ってことでUbuntuにも興味は持っておりまして。
で、この際だから入れてみた。
インストーラはDebianみたいにExpert Installとかないみたいで、なんか勝手にもりもりパッケージ入れられたけどまあデスクトップ用途ならありだろう。
んで、パーティションを切るときに気づいたんだけども、Ubuntu 9.10だとデフォルトのファイルシステムにext4が使用される。
ext3とext4の違いとか知らないわけだけども、まあデフォルトになってるんだから使ってやるか、ということでext4でパーティション切って入れてみた。
インストールを終えたものの、Windowsのほうの環境がまだｇｄｇｄなもんでとりあえずWindowsの環境整備をしているんだけども、そこでext4ってWindowsからアクセスできるの？っていう疑問がふとわいてきた。
そこで調べてみた。
結論から言うと、条件付きで可能。
ext2/3/4は後方互換（backward compatible）性がある。
これはどういうことかというと、ext3はext2を純粋拡張したものであり、ext4はext3を純粋拡張したものであって、ext2で持っている基本構造自体には変化がないということだ。
だから、ext2のデータはそのままext4で扱える。
ext2ファイルシステムをext4ファイルシステムにするのは簡単なのだ。
しかし、その逆となると簡単ではない。
というのは、ext3/4ファイルシステムのデータは、それらのファイルシステムで拡張されたext2では定義されていない固有の情報をすべて切り落とさなければ、ext2ファイルシステムにおいては異常なデータとなってしまうからだ。
んで、今現在Windowsからextうんたらにアクセスできるようにするソフトっていうかドライバっていうかってのはあんまりない。と思う。
ぱっと探して見つけたのは以下。
とりあえず最後のやつ以外は試したけどだめだった。
最後のやつを試さなかったのは、inodeが128byteを超えるものはサポートしないって明示してあったから。
Ubuntu 9.10では256byteがデフォルトっていうね。
ところで、ファイルシステムを作成するときにはこっそりフィーチャー（feature）と呼ばれるオプションがついている。
そのデフォルト値が/etc/mke2fs.confに書かれていたりするんだけど、それのext4がUbuntuだとこんなかんじ。
ext4 = {
features = has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
inode_size = 256
}
んで、このなかのextentsオプションが付与されてファイルシステムが作成されていると、上記のext3まで読めるやつでも読めなくなっちゃうようだ。
とりあえず、ext2fsdではextentsオプションをはずせば読める。
一応書けもする。
常用したら絶対何かが起きると思うけど。
ほかのソフトは知らない。
ちなみに、extentsってどういうオプションかっていうと、まあ詳しくはここを見てもらうと。
簡単に言えば、ファイルの中身（データ）ってでっかいファイルだとばらけるわけで、そういう時ext3までは、直接参照だけじゃ間に合わないんで間接参照することにして、間接参照の先で直接参照してってな具合になってたのを、「次のnブロックにデータがあるよ」っちゅー風な言い方をするように変えるんだぜ、っていうオプション。
なんか簡単にいえてない気がするけど気のせいかも。
重要なのは、extentsオプションつけてファイルシステム作ると、今までのLinuxのファイルシステムにおけるファイルの実データへの参照方法とは根本的に違う参照方法になっちゃうってこと。
そりゃext3まで対応してるソフトっていうかドライバっていうかでも読めない。
なので、解決方法は以下のどれか。
- extentsオプションをはずしてファイルシステムを作成する
- extentsオプションを後から消す（たぶんうまくいかない気がする）
- ext4使わないでext3使う
- VM使ってファイル共有
- extents対応のソフトを作るか作ってもらう
- 見えなくていいと開き直る
1は
# mke2fs -t ext4 -O ‘^extents’ /dev/sda1
とかってかんじか/etc/mke2fs.confあらかじめ書き換えるか。
2は
# tune2fs -O ‘^extents’ /dev/sda1
# e2fsck -fpDC0 /dev/sda1
みたいな。
うまくいくのかわかんないけど。
ってかたぶん無理なんだろうな。
ちなみにUbuntuだとどうもインストールプロセスでは1はできないっぽかった。
Debianのインストーラならエキスパートモードで普通にシェル立ち上げて自分でファイルシステム作ればいいんだけど、良くも悪くもUbuntuはWindowsユーザ層みたいなのをターゲットにしてるのか、インストールプロセスが簡易な反面細かいカスタマイズができないっぽかった。
あんまりいじってないから実はできるんだけど気づいてないだけかもしれないけど。
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void 
Life 
Earth 
Wind 
Water 
Fire