hasegaw blog

ふしおにお、インフラエンジニアの早期帰宅支援アイテム「i○ドライブⅡ」を発表

hasegaw — 2012-04-01T07:58:13+09:00

早期帰宅ソリューションを提供するふしおにおは、インフラエンジニア双六をより有利に進めるためのアイテムカード「i○ドライブⅡ」を発表しました。

i○ドライブは、i○オカエリープラットフォームをベースとした日々の帰宅を高速化するソリューションで、サーバ擬人化ユーザ会が提供するインフラエンジニア双六の追加アイテムです。双六ゲーム中にてインフラエンジニアが本アイテムを使用すると、業務のボトルネックを解消できます。月初や期末の書類業務にも有効。スムーズな帰宅と団欒を約束し、家族愛を深めます。

今回発表するi○ドライブⅡでは、サイコロの出目が 2X ではなく +6 されることにより、出目の期待値が 7.0 から 9.5 へと上昇しました。また、出目の期待値が向上しただけでなく、双六プレイヤー側のプリンターを有効利用することによりアイテムカードのコスト削減を実現。同等性能のアイテム群では突出した、優れたコストパフォーマンスを実現しました。

厚めの光沢紙に印刷することで、より高級感溢れるアイテムカードとしての利用も可能です。

製品マネージャのふしおにおジョー・タロウは、「i○ドライブⅡはインフラエンジニアの生活スタイルを変える最高のアイテムであることを確信しています。日本は世界でも核家族化が極度に進行しつつある地域です。日本のインフラエンジニアの皆様には、このデバイスを手に入れて業務に打ち勝ち、夜の町に繰り出して素敵なパートナーと巡り会っていただきたい。シュワッチ！」とコメントしています。

なお、製品の出荷時期は8月中旬(夏コミと同時期)の見込みです。

(2012年4月2日追記) 私がブースの人としてコミケデビューできる日がきたら頒布したいと思いますﾟ+.(･ω･)ﾟ+.ﾟ

OpenIndiana でイーサネットデバイスのリストを表示する

hasegaw — 2012-03-12T00:16:30+09:00

zpool を旧ディスクから新ディスクにコピーしたついでに OpenIndiana へ移行しようとしたファイルサーバ、イーサネットのデバイス名が ifconfig -a で表示されてこないのでしばらく放置してあったのをやっとこネットワークに繋ぎました。

# dladm show-phys LINK MEDIA STATE SPEED DUPLEX DEVICE e1000g0 Ethernet up 1000 full e1000g0 e1000g1 Ethernet unknown 0 half e1000g1

まさか Intel の NIC でドライバが足りてないなんてことはないよなぁとか思ったりデバイス名なんだろうとか思っていたけど dladm show-phys で出てくるんですね。ってことで /etc/hostname.e1000g0 を作ったりとか色々して作業完了。

リゾルバ設定で /etc/nsswitch.conf のフルパスを思い出すのにちょっと時間かかった。もう歳ですね……。

大量のUSBフラッシュメモリを再フォーマットする

hasegaw — 2012-03-10T14:46:31+09:00

MacOS X上で100個オーバーなUSBメモリの内容をガンガン消したかったのでスクリプトを書きました。

以前に消去前の USB メモリ（恐らくイメージを事前作成し展開）のデータを dd で読み取って split して md5 で一通りチェックしたら最初の 30MB 分ぐらいにデータが入っていることがわかったので、まず dd でゼロクリアします。その後 MacOS X 上で FAT16 のファイルシステムを作成し、終わったらイジェクトします。

usbdisk_format.sh
#!/bin/sh

DISK=$1
if [ "x$DISK" == "x" ]; then
        echo Usage: $0 /dev/disk1
        exit 1;
fi
diskutil unmountDisk $DISK 2>&1 > /dev/null
if [ $? -ne 0 ]; then
        echo $DISK: Unmount failure.
fi
mount | grep -q "$DISK"
if [ $? -eq 0 ]; then
        echo $DISK: Still mounting. dont format this disk.
        exit 0
fi


sudo dd if=/dev/zero of=$DISK bs=1m count=30 2>&1 > /dev/null
if [ $? -ne 0 ]; then
        echo $DISK: dd failure.
fi


diskutil partitionDisk $DISK  MBR 'MS-DOS FAT16' FUSION-IO 100% 2>&1 > /dev/null
if [ $? -ne 0 ]; then
        echo $DISK: format failure.
        exit 1
fi


diskutil unmountDisk $DISK 2>&1 > /dev/null
if [ $? -ne 0 ]; then
        echo $DISK: Unmount failure.
fi


exit 0

このスクリプトは引数して /dev/diskX といったデバイス名をとりますが、毎回これを指定するのは面倒なので、 USBメモリを見つけて上記スクリプトを叩くスクリプトを作りました。
このスクリプトは /dev/disk* ファイルを見つけて、そのデバイスが目的のブロックデバイスであるか、ブロックデバイスの容量やデバイス名などをベースに判断し、条件にあうデバイスは上記のスクリプトを並列実行し初期化します。

usb_batch.sh

#!/bin/sh


test_fusion_usb() {
        DISK=$1
        diskutil info $DISK | grep -q 'USB DISK Media' 
        if [ $? -ne 0 ]; then
                echo SKIP_1
                return 1;
        fi
        diskutil info $DISK | grep -q '1.0 GB (1038090240 Bytes)' 
        if [ $? -ne 0 ]; then
                echo SKIP_2
                return 1;
        fi


        # echo $DISK is USB
        return 0;
}


DISKS=`ls -1 /dev/disk[0-9] /dev/dsk[0-9][0-9]`


for d in $DISKS; do
        test_fusion_usb $d
        if [ $? -eq 0 ]; then
                echo Clearing $d
                sh usbdisk_format.sh $d &
        fi
done

あとは USB メモリを MacBook Air に刺しまくってスクリプトを実行するだけ・・・・！！

・
・
・

MacBook Air が落ちました。バスパワーが足りなくて、安定して並列初期化できるのは 4 枚ぐらいまでのようです。また一番大変なのは USB メモリを包装するビニール袋との戦いでした。

システムボードと干渉するPCI-Xカードを加工する

hasegaw — 2012-03-05T00:46:43+09:00

搭載先マシンのシステムボード上にあるヒートシンクなどと干渉する PCI-X カードの一部端子を切り落としました。
PCI-X は PCI の上位互換なので、パフォーマンスの低下を許容できれば PCI スロットでも動作します。ただし場合によっては PCI-X の追加分の端子部分が他のコンポーネントと衝突することがあります。追加分の端子は接続されていなくても PCI 相当でリンクできるので、切り落としてしまうという方法です。たぶんよくやられている事でしょう。。。。

奥が加工前、手前が加工後のカードです。

使用した道具

ホームセンターで下記３点を購入してきました。上から順番に

1. プラスチックカッター OLFA PC-L
2. 分厚い素材に対応できるカッターナイフ。ムラテック H-13
3. 適当にヤスリ

です。

加工順序

PCI-X カードは大抵複層基板なので、無理に切り取り部分をへし折ろうとするとカードの中身を痛めてしまうため、できるだけ力を加えないよう注意しながら作業します。

工程１
プラスチックカッター（１）でまず端子のつけねに切れ込みを入れます。このときカッターは右から左へ動かすイメージでとりあえず跡をつけることを目標にします。

工程２
十分に跡がついてきたら、カッターナイフ（２）で端子の付け根にできた溝を深くしておきます。場合によってはこの工程は不要かもしれません。

工程３
続いてプラスチックカッター（１）でこの溝を広げていきます。プラスチックカッター（１）を左から右へ進めると一気に基板が削れ、溝が深くなっていきます。

工程４
上記を表面、裏面から済ませます。

工程５
カッターナイフ（２）で溝の中を切ります。表裏から削られた端子部分は簡単に切り落とせるはずです。

工程６
これまでの工程でカードにはたくさんのバリが発生しています。この部分をヤスリでフィニッシュします。端子部分が残らないぐらいまでヤスリで削ってしまったほうがよいかもしれません。
なお、このエントリの最初に掲載されている写真の「加工後のカード」は、そのままでは認識されず、ヤスリで端子部分をもっと綺麗に削り落とすことで認識されるようになりました。

工程７
削りかすを除去します。削りかすには絶縁物質のほかに導通する物質もあるので、ちゃんと取り除かないとショートするかもしれません。うまい方法を思いつかなかったので掃除機で軽くカスを吸い取る程度にして、かすがカード上に残っていないか肉眼で確認しました。

加工完了！

[root@hoge ~]# lspci | grep -i qlogic
0e:00.0 Fibre Channel: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X HBA (rev 02)
0e:01.0 Fibre Channel: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X HBA (rev 02)

iSCSI-SCST を試してみる

hasegaw — 2012-03-04T03:59:07+09:00

SCST インストールメモ on CentOS 5.7 の続き。FCのケーブルを準備するまで我慢ができなかったのでとりあえず iSCSI でエクスポートしてみた。

iscsi-scst カーネルモジュールの作成

971 cd work/scst/trunk/
972 cd iscsi-scst/
976 ls -l
977 less README
978 make all
979 make install

iscsi-scstd.conf を作成

[root@localhost trunk]# cat /etc/iscsi-scstd.conf
Target iqn.1994-05.com.redhat:24d563eb3c6:storage

指定した IQN は、 /etc/iscsi/initiatorname に指定されていたものをそのまま借りました:p

カーネルモジュールのロード

1027 modprobe scst
1028 modprobe iscsi-scst
1029 modprobe scst_disk
1030 modprobe scst_vdisk

イメージファイルをiSCSIエクスポート

957 scstadmin -open_dev vdisk1 -handler vdisk_fileio -attributes filename=/vdisk1.dsk
1077 scstadmin -add_target iqn.1994-05.com.redhat:24d563eb3c6:storage -driver iscsi
1081 scstadmin -add_group hosts1 -driver iscsi -target iqn.1994-05.com.redhat:24d563eb3c6:storage
1113 iscsi-scstd &
1130 scstadmin -add_lun 0 -driver iscsi -target iqn.1994-05.com.redhat:24d563eb3c6:storage -device vdisk1
1131 scstadmin -enable_target iqn.1994-05.com.redhat:24d563eb3c6:storage -driver iscsi
1132 scstadmin -set_drv_attr iscsi -attributes enabled=1

イニシエータを準備し接続

今回は Windows 7 Ultimate の iSCSI イニシエータを有効化して接続しました。
コントロールパネルから「iSCSIイニシエーターのプロパティ」を開き、ターゲットとして SCST が動いている IP アドレスを指定して「クイック検索」ボタンをクリックします。

ターゲットが問題なく動作していれば、「検出されたターゲット」欄にターゲット側 IQN が表示されますので、目的の IQN を選択して「接続」をクリックします。無事に接続されれば、ターゲット側の領域が論理ディスクデバイスとして認識されているはずです。

構成情報を /etc/scst.conf に出力

1133 scstadmin -write_config /etc/scst.conf
1134 cat /etc/scst.conf

I/O試験

1137 iostat -mtx /dev/sda 1 | grep sda
この状態でイニシエータ側から負荷をかければ Linux 側で I/O の発生を確認できる

所感

SCST のコンパイル時点から感じていたことですが。。。。 trunk のコードベースで試したからか、既存のドキュメント類からオペレーションが変わっていて、読み替えるのがちょっと大変でした。。。。正直まだ成熟したとはいいづらいね。どのタイミングのコードを使うかなど決断して闘う必要がありそう。

SCSTインストールメモ on CentOS5.7

hasegaw — 2012-03-04T02:00:14+09:00

憶えがき。

参考にしたサイト

SCSTのインストール
http://homepage1.nifty.com/~ayumi/article0001.html

855 cd
856 mkdir work
857 cd work
858 svn co https://scst.svn.sourceforge.net/svnroot/scst

カーネル 2.6.28 のビルド
808 tar xvzf linux-2.6.28.3.tar.gz
814 ln -s linux-2.6.28.3 linux-2.6.28
815 patch -p0 < work/scst/trunk/scst/kernel/scst_exec_req_fifo-2.6.28.patch
816 cd linux-2.6.28/drivers/
819 cd scsi
821 mv qla2xxx/ qla2xxx_orig
822 ln -s ~/work/scst/trunk/qla2x00t/ qla2xxx
823 cd ..
824 cd ..
825 pwd

826 cp /boot/config-2.6.18-274.el5 .config
827 make menuconfig
828 vim .config
カーネルコンフィグレーションオプションの指定
829 vi Makefile
EXTRAVERSIONの変更
830 make -j8 bzImage; make -j8 modules && make -j8 modules_install
831 make install
832 cd /boot
833 ls -l
834 zcat initrd-2.6.18-274.el5.img | cpio -it
835 zcat initrd-2.6.28.3-scst.img | cpio -it
836 vi /boot/grub/menu.lst
自動起動するカーネルの指定

SCST関連のビルド
1. scst
941 cd work/scst/trunk/scst
943 cd src
944 make
945 vim +1654 scst_sysfs.c
バージョン判定でコケているので修正
946 make
947 make all
948 make install

2. qla2x00t
951 cd ..
952 cd qla2x00t/
961 make -C /root/linux-2.6.28/ M=$PWD
962 make -C /root/linux-2.6.28/ M=$PWD modules_install

3. qla2x00-target
963 cd ..
964 cd qla2x00t/qla2x00-target/
967 make
968 make install

4. scstadmin
972 cd scstadmin/
973 make
974 make install

975 cd /lib/modules/2.6.28.3-scst/extra/
976 ls -l

カーネルモジュールのロード
1002 modprobe scst
1007 modprobe qla2x00tgt
1010 modprobe scst_disk
1011 modprobe scst_vdisk

ターゲットの操作
1012 scstadmin
1014 dd if=/dev/zero of=/vdisk1.dsk bs=1024k count=64
1018 scstadmin --help
1019 scstadmin -open_dev vdisk1 -handler vdisk_fileio -attributes filename=/vdisk1.dsk
1021 scstadmin -set_dev_attr vdisk1 -attributes t10_dev_id=0x1234
1022 dmesg
1025 scstadmin -add_group HOST01 -driver qla2x00t -target 21:00:00:e0:8b:82:87:08
1026 scstadmin -add_lun 1 -driver qla2x00t -target 21:00:00:e0:8b:82:87:08 -group HOST01 -device vdisk1

この先は FC ケーブルが必要と思われる。

ML110 G7を買ってみた

hasegaw — 2012-03-03T13:20:40+09:00

ML115 G1 クラスタの処分も視野に入れて NTT-X で特価になってるのを一台ポチってみました。

他の方がレビューされているので基本はそれを見ればいいと思いますがヘタレとして自分が気づいた点のみまとめます。

システムボード仕様は 3xx シリーズ並？

POST画面のほかBIOSコンフィグレーションも 3xx シリーズと同じように見えます。 3xx シリーズをいじりたいけど手が届かない人には入門機としてありじゃないでしょうか。

スクリューレスで快適メンテ

度々構成を変えるような使い方には無手居るケースだと思います。ただ PCIe スロットまわり、とくに一番下のスロットは抜き差し大変かもしれない。

電源は 350W

350W の電源がのっています。あと PCIe 用の 6 ピン電源コネクタはないので SLI とか CorssFire とか想定して買うとちょっとガッカリします。まあそこまでやるなら電源ごと交換するのでしょうが。

PCI スロットなし

新品で数千円レベルで入手できるカードは刺さらないということです。イーサネットは標準で２系統ありますが、スループット度外視でお手軽に追加したいような時には注意。

PCIe バスのレーン数が....

しっかり確認していませんが電気的に PCIe x16, PCIe x8, PCIe x8, PCIe x4 なのですが、もしかするとその上流で帯域が足りないブリッジチップがあるかもしれない感じです。 PCIe x16, PCIe x8, PCIe x4, PCIe x4 ぐらいのつもりで買っていたほうがいいよ。なお、いわずもがな Gen2 ですね。

下の方のスロットほど帯域幅は大きくなっているので、高負荷なデバイスはそちらに優先的に挿しましょう。

まとめ

ほとんど PCIe といえばビデオカードぐらいしか想定していないパーソナルユースで売ってる程度のシステムボードと比べれば、ごついカードを挿しても安定して動きました。ちょっとした検証やオモチャにするには十分なスペックですが、 CPU やメモリや電源を変えても PCIe バス幅だけはどうにもならないので、本気ならサーバ用システムボードもしくは相当品を買いましょう。

補足

製品スペックをよくみたら PCIe のスロットは x16, x4 ,x4, x1 と書いてあった。納得。

フラッシュメモリのストライピングは善か悪か？

hasegaw — 2012-02-20T02:24:29+09:00

SSDなど、フラッシュメモリを用いたストレージデバイスは非常に高速です。このようなデバイスをストライピングするとさらに上を目指せる、、、ように感じられますが、実はストライピングで常にアプリケーションの性能が上がるわけではありません。

デバイス単体、２台ストライプのレイテンシ特性

以下のグラフは、フラッシュメモリデバイスへのランダム4KB書き込み時のレイテンシ分布（ドライブ単体および２台をストライプ）を示したものです。

グラフ１

左側がいちばんレイテンシが低い状態、右にいけばいくほどレンテンシが増えていった状態を示していおり、線が左に寄っているのは、すなわち高速に応答していることを示しています。

デバイス単体の場合（赤）、レイテンシ分布は非常に高速な状態（１）に偏っており良好な状態です。ストライプした場合（青）、先と比べると（２）の値が高くなっていて、つまりレイテンシが大きくなっていると言うことになります。この状態であれば間違いなく赤、つまりデバイス単体の性能のほうが応答が早いことになります。

この結果ですが、すこし条件を変えて測定してみると —— 以下のようになります。

グラフ２

このグラフでは、ストライプ構成（青）のほうがデバイス単体（赤）よりよいレイテンシ性能を示しています。

条件の違いは？

この先の２つのグラフ、一体何を変えたと思いますか？　　答えはI/Oスレッド数です。

グラフ１ …… 1スレッド
グラフ２ …… 64スレッド

つまりグラフ１の場合よりグラフ２の場合のほうが大きなワークロードがかかっています。つまりワークロード次第でレイテンシ分布は変化します。

さて。
デバイス単体で使ったほうがお得でしょうか？
それとも、ストライピングしておいたほうがお得でしょうか？

ヒント

複数デバイスにストライプすると、各デバイスからの応答を待ち合わせる必要があるため、レイテンシが幾らか悪化する。
転送するデータのサイズに比例して、フラッシュメモリのレイテンシは変化する。

フラッシュメモリデバイスのレイテンシ差がアプリケーションに与える影響

hasegaw — 2012-02-19T02:14:53+09:00

たまにはブログを書こうかと。今日はこのブログではじめてフラッシュメモリの話題を扱うことにしましょう。

個人的に大好きなプレゼンテーションがあります。タイトルは Mythbusting Flash Performance 、元Sun（現Oracle）の Solaris プラットフォームエンジニアリングのバイスプレジデント Bill Neshim 氏が Flash Memory Summit 2011 のキーノートとして講演した際のスライドのようです。

このプレゼンテーションには衝撃的なグラフが入っていて、これを見たとき衝撃を受けました。それ以来このプレゼンテーションはお気に入りとして常にマシンの中に入っています:)

予期可能なレイテンシ性能のフラッシュメモリデバイス、そうでないフラッシュメモリデバイス

フラッシュメモリデバイスは、使用されているNANDフラッシュメモリのパッケージごとの性能もありますが、それを管理・制御するコントローラにより、最終的なデバイスの仕上がりが大きく変わることが知られています。

フラッシュメモリデバイスの性能は IOPS (単位時間あたりのIO回数)と帯域幅で語られがちですが、さらにレイテンシという軸で探ってみると、デバイスの本当の性能がよく見えてきます。

IOPSの比較

以下は、先のプレゼンテーションからの引用です。具体的なデバイスの機種名は明かされていませんが、2つのフラッシュメモリデバイスのIOPS性能を比較しています。

Device A

Device B

このふたつの違いは明白です。前者は書き込みスレッド数により IOPS 性能が決まってくる、つまり性能が予期できることがわかります。後者は、もちろんスレッド数が少ない方がIOPS数が多いもののおよそランダムな状態です。これが、性能が予期できないフラッシュメモリデバイスの特性です。

レイテンシの比較

続いて、次のスライドは2つのデバイスのレイテンシ性能を比較しています。

縦軸は頻度、横軸はIO時に発生したレイテンシの大きさです。つまりグラフが左側に寄っていればそれだけ応答が速いデバイスである、と見ることができます。

このグラフで登場している2つのデバイスは、実際に Oracle の本番環境で利用されており、非常にレイテンシ特性が似ています。しかし、 OLTP ワークロードをかけた際のグラフを見ると、 Dev1 はレイテンシが大きくなる頻度が Dev2 より大きい —— つまり、実際のアプリケーション負荷をかけるとレイテンシがより悪化するデバイスである、ということです。

これについて Bill 氏は「I/Oのうち最も遅い 1% がデバイスの性能を決める。しかし、多くのデバイスベンダはこの部分の軽く見がちだ」と述べています。

どうして氏が 1% に拘るのか……それは次のスライドに答えがあります。

このスライドは、さきほどの「最も遅い1%」がデータベースの OLTP に性能にどのような影響をもたらすかを示しています。縦軸はデバイスのレスポンスタイムタイム、横軸は時間です。このグラフでは、 Dev 2 が非常に安定したレスポンスタイムで応答しているのに対し Dev 1 のレスポンスタイムは明らかにムラがあります。

Dev 2 を使ったデータベースでは一定の間隔で応答してきますが、 Dev 1 は、まるで混雑した道路で渋滞にハマっているかのように動いたり止まったり……を繰り返しているのです。この結果、データベースの実行速度には大きな差が現れるのです。

まとめ

フラッシュメモリデバイスの性能は IOPS (単位時間あたりのIO回数)と帯域幅で語られがちです。しかし、それだけでなく、レイテンシが安定しているか、という観点での評価もとても重要です。それも一定時間の平均値ではなく、レスポンスタイムの分布まで含めてはじめて、アプリケーション性能への影響がわかります。

p.s. @yoshikaw さんにエントリ中のバグをご指摘いただき修正しました。ありがとうございます！

変なファイル名によるイタズラ

hasegaw — 2012-01-12T22:38:08+09:00

へぇぇぇぇ。

[sandbox@proliant2 work]$ touch -- '-rf' '~' [sandbox@proliant2 work]$ strace rm * execve("/bin/rm", ["rm", "-rf", "~"], [/* 23 vars */]) = 0 brk(0) = 0x87c000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f840a966000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=94094, ...}) = 0 mmap(NULL, 94094, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f840a94f000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\357\1n?\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1995840, ...}) = 0 mmap(0x3f6e000000, 3814616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3f6e000000 mprotect(0x3f6e19a000, 2093056, PROT_NONE) = 0 mmap(0x3f6e399000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x199000) = 0x3f6e399000 mmap(0x3f6e39e000, 21720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3f6e39e000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f840a94e000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f840a94c000 arch_prctl(ARCH_SET_FS, 0x7f840a94c720) = 0 mprotect(0x3f6e399000, 16384, PROT_READ) = 0 mprotect(0x3f6de20000, 4096, PROT_READ) = 0 munmap(0x7f840a94f000, 94094) = 0 brk(0) = 0x87c000 brk(0x89d000) = 0x89d000 brk(0) = 0x89d000 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=99154656, ...}) = 0 mmap(NULL, 99154656, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8404abc000 close(3) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 opost isig icanon echo ...}) = 0 lstat("/", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 newfstatat(AT_FDCWD, "~", {st_mode=S_IFREG|0664, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0 unlinkat(AT_FDCWD, "~", 0) = 0 close(0) = 0 close(1) = 0 close(2) = 0 exit_group(0) = ? [sandbox@proliant2 work]$

シェルによりワイルドカード指定で見つかったファイルの ~ カレントディレクトリパスに置き換えられないため問題ないのね。

しかし意図的にファイルを置いておくことで -i を迂回できるね。怖い……！

※Fedora 14 の環境でためしました。