ZFS RAID-Zの動的ストライプ幅

ZFSの動的ストライプ幅（dynamic stripe width）について解説したサンマイクロシステムズ株式会社のスライドが、ちょっと誤解を招く表現になっているのではないかと思う。問題のスライドは、2009年3月6日に開催されたOpenSolaris Night Seminar配付資料の78～80ページである。その後のセミナーでも同じ図を使っている。

今注目の Solaris ZFS!! っていうかファイルシステムって何？
http://sdc.sun.co.jp/events/nightSeminar/PDF/OSNS-Solaris_ZFS-20090306.pdf

ディスク5本で構成したRAID-Zにおいて、大きな書き込みも小さな書き込みも5本のディスクにわたって行われ、それぞれのディスクに書くサイズを小さくすることで書き込みサイズを調節しているというような図になっている。しかしRAIDのストライプ幅というと、通常は使用するディスク本数のことを指すはずだ。この図は常に5本でストライプしているから、動的ストライプ幅に全然なっていない。

ZFS開発者のBill MooreとJeff Bonwickが2008年のSNIA Storage Developer Conferenceで行ったチュートリアルのスライドは別の図を使っている。PDFの18ページ、ビデオはPart2の3分35秒付近である。

ZFS  The Last Word In File Systems
http://www.snia.org/events/storage-developer2008/presentations/monday/JeffBonwick-BillMoore_ZFS.pdf

Video: The Ultimate ZFS Tutorial - Part 2
http://blogs.sun.com/storage/entry/video_the_utlimate_zfs_tutorial1

この図は、オレンジ色の書き込みは5ストライプ×2、黄色の書き込みは4ストライプ、緑は4ストライプ、赤は2ストライプというように、使用するディスク本数が書き込みごとに変わるということを示している。これが動的ストライプ幅である。

ディスク2本にストライプする場合はミラーリング相当になる。RAID-5の本来の意味合いは、ディスク1本の障害でもデータを失わないようにすることだ。2本ストライプの場合は、残った1本からデータを復旧できるのでRAID-5と同等の目的を達成できる。

これについての質疑がzfs-discussにもあった。関連するコードはvdev-raidz.cのvdev_raidz_map_alloc()である。

raidz and 512 byte files
http://www.opensolaris.org/jive/thread.jspa?messageID=47396

あなたのデータは既に壊れているかもしれない（Silent Data Corruption）

LHC（(Large Hadron Collider、大型ハドロン衝突型加速器）を建設したCERNは、数多くのサーバやディスクで実験データを保存・解析している。いうまでもなくデータの整合性・完全性が非常に重要である。サーバやディスクのデータは本当に大丈夫なのだろうか。そこで、fsprobeというプログラムを作って実験してみた。

fsprobeの処理は非常に単純である。

1. 1MBの既知のビットパターンをディスクに書き込む。これをファイルが2GBになるまで繰り返す。
2. 1MBずつファイルを読んで、書き込んだはずのビットパターンと比較する。これを2GBまで続ける。

この処理を数千台のサーバで数ヶ月にわたって実行したところ、書き込んだはずのパターンが壊れているという事象がいくつも見つかった。3000ノードで5週間走らせたときは、100ノードで500個のエラーが見つかった（参考文献1）。4000ノードで走らせたときは（期間不明）、1400個の事象が230ノードで見つかった（参考文献2）（注）。実際の破損パターンを参考文献2で見ることができる。

また、ディスク上にあるファイルのチェックサムと、以前に計算してテープに保存しておいたチェックサムを比較したら、33,700ファイル（約8.7TB）のうち22ファイルで不一致が発見された。1500個に1個の割合である。

我々はディスクドライブというものを、十分信頼できる装置だと考えていて、そこにあるデータがいつのまにか壊れることなど想像もしない。エラーを検出し、訂正可能であれば修復する仕組みがいろいろな部分に組み込まれている。RAID-5のパリティもそのひとつであるし、ディスクドライブ自体もCRCチェックサムを使ってブロックの整合性を確認している。もしビットエラーが発見されたら、それは上位レベルに報告され、OSやアプリケーションが認識できるはずだ。

しかし上記の実験結果は、このような様々な仕組みをすり抜けるケースがかなりあるということを示している。何もエラーが報告されないのにいつのまにかデータが破損していることを「Silent Data Corruption」と呼ぶ。おそらくこれまではデータ容量やトラフィックが比較的少ないのでほとんど起きなかったか見過ごしていたのだろう。あるいはデータが破損している事象を経験しても、これはアプリケーションのバグか誰か他の人の操作ミスなんだろうと考えていたのかもしれない。

CERNの研究者たちはこう結論づけている。Silent Data Corruptionを撲滅することは不可能であり、こういった問題があるということを前提として対策を組み込まなければならない。そのひとつがアプリケーションレベルでのチェックサム検査である。書き込むときにチェックサムを取ってどこかに保存しておく。そして読み込み時に計算した値と比較する。

ZFSはエンド・ツー・エンドのチェックサム処理を実装していて、ディスク上のデータが破損しているかどうかを、ファイルシステムのレベルで確認する。当然、これによるCPU処理負荷が上乗せされる。従来のファイルシステムは、それによる性能劣化を嫌って実装しなかったわけだが、ZFSの開発者たちは、現在のCPUは性能が劇的に向上しているからもはや問題にならないはずと考えて、エンド・ツー・エンドのチェックサム処理を組み込んだ。

ZFSが使えないWindowsシステムで我々はどうすればよいか。バックアップは完璧ではない。破損したデータをバックアップしているかもしれないからだ。せいぜい、定期的にバックアップを取り、それを複数世代にわたって保存することくらいしか考えつかない。あとはNTFSが同様な対策を組み込むのを気長に待つしかない。

（参考文献1）
Data integrity
Bernd Panzer-Steindel, CERN/IT
Draft 1.3 8. April 2007
http://indico.cern.ch/getFile.py/access?contribId=3&sessionId=0&resId=1&materialId=paper&confId=13797

（参考文献2）
Silent Corruptions
Peter.Kelemen
CERN After C5, June 1st, 2007
http://fuji.web.cern.ch/fuji/talk/2007/kelemen-2007-C5-Silent_Corruptions.pdf

（注）
4000ノードテストは、3000ノードテストからの継続かもしれない。

ZFS vs. NTFS

ZFSとNTFSを機能レベルで比較してみた。ざっと調べただけなので、見落としや誤解しているところがあるかもしれない。とくに「何かが無い」ということを証明するのは結構難しい。またNTFSはWindowsのみの実装なので、NTFS自身の機能ではないものも含まれる。

■ZFSにあってNTFSにないもの

エンド・ツー・エンドのチェックサム

データ自己修復

シンプロビジョニング
Windowsでもできるが、現在のNTFSの設計ではうまく動かないというマイクロソフト技術情報もある。

Recommendations for thin-provisioned volumes for computers that run Windows Server 2008, Windows Vista, Windows Server 2003, or Windows XP
http://support.microsoft.com/?scid=kb%3Ben-us%3B959613&x=10&y=10

ZFSでも、zvolのシンプロビジョニング（sparse volume、疎ボリューム）は推奨していない。
http://docs.sun.com/app/docs/doc/819-2240/zfs-1m?l=ja&a=view

クローン

ダブルパリティRAID（RAID-Z2）

ハイブリッドストレージプール
フラッシュメモリを活用してブートを高速化するReadyBoost機能がWindows Vistaにある。これに対してZFSのハイブリッドストレージプールは任意のボリュームで使用可能で、実行ファイルだけでなく任意のファイルのアクセスを高速にできる。

De-dupe
まもなくZFSに実装される模様。

■NTFSにあってZFSにないもの

Windows環境との「完璧な」親和性
ZFS + SambaまたはSolaris CIFSサービスという組み合わせが、Windowsシステムを完璧に再現できているかというと、多少は違いがあるだろうと思う（根拠はない）。なので、カギ括弧付きの「完璧な」親和性と書いている。

255バイトを超える日本語ファイル名の正しい処理
ZFSのファイル名最大長は255バイト。NTFSは255文字。UTF-8で日本語1文字は3バイトで表現されるので、ZFSにUTF8でファイル名を格納すると、86文字目以降が切り捨てられてしまう。日本語だけでなくロシア語でも同じ問題が起きていて、ZFSの機能拡張要求が提出されている（Bug ID 6802759）。
http://bugs.opensolaris.org/view_bug.do?bug_id=6802759

■どちらにもあるもの

トランザクションベース書き込み時コピー（CoW、Copy On Write）
ファイルシステムへの変更がAtomicだからディスク上で不整合が出ないという仕組みだと考えると、Vista以降のTransactional NTFSはAtomicな変更をサポートする。
http://en.wikipedia.org/wiki/Transactional_NTFS

ミラーリング（RAID-1）

シングルパリティRAID（RAID-5、RAID-Z）

スナップショット
WindowsはVSSで実現。

リモートレプリケーション
WindowsはDFSで実現。

圧縮

ボリュームのオンライン拡張
NTFSのダイナミックディスクはオンラインで拡張可能。

Sun MicrosytemsのPSARC、ついでにZFSの重複排除（Dedupe）

OpenSolarisのサイトを見ていると「PSARC」という略語をときどき見かける。たとえば以下のページに出てくる。

Flag day: PSARC/2008/518 ZFS space accounting enhancement
http://jp.opensolaris.org/os/community/on/flag-days/pages/2008082502/

これは「Platform Software Architecture Comittee」の略ではないかと思う。参考にしたのは以下のスレッドである。

「開発プロセス 」付録A インターフェース の分類法
http://opensolaris.org/jive/thread.jspa?messageID=163251

Sun Microsystems社内にある検討委員会のような組織のことだろう。そこでどんな議論がなされているかは表に出てきてないと思う。OpenSolarisはオープンソースであるが、これは必ずしも開発プロセスがオープンであることを意味しない（注1）。

たとえばZFSの重複排除機能（Deduplication）は、Jeff BonwickとBill Mooreが開発中であることが2009年3月に明らかにされたあと（注2）、Kernel Conference Australia 2009の基調講演にふたりが登壇するまで詳細が不明だった。基調講演は見ていないが、資料がいずれネットで公開される予定である。

ちなみにZFSは、ブロックレベルのハッシュで重複を検出しているようだ（注3）。したがって、ZFSファイルシステム・zvolに関わらず、すべての上位サービスで重複排除が利用できだろう。圧縮と同じくSPA（Storage Pool Allocator）に実装したのではないかと思う。

（注1）オープンソースとオープン開発プロエスについて、zfs-discussの以下のスレッドで議論されていた。
deduplication
 http://opensolaris.org/jive/thread.jspa?threadID=107736

（注2）Jeff BonwickがDeduplicationについて書いたスレッド
ZFS and deduplication?
 http://opensolaris.org/jive/thread.jspa?threadID=98816

（注3）
De-duplication: possible to identify duplicate files?
http://opensolaris.org/jive/thread.jspa?threadID=107916

OpenSolarisのバグとソースコード修正箇所の対応付け

私はカスタマサポートエンジニアだが、障害対応の時にソースコードを参照することがよくある。日本のユーザは修正内容について細かく知りたがる。Webで公開している技術情報ではもちろん、バグデータベースに開発者が書いたコメントでも説明しきれない。そう言うときはソースコードにあたる。

OpenSolarisに関わることが増えてきたので、登録されたバグに対してソースコードのどこが修正されたのかを見つける方法を調べた。ちょっと面倒だが、OpenSolarisのコードリポジトリ（http://repo.opensolaris.org/）にアクセスできれば簡単なのかもしれないが、私のアカウントは権限がないと拒否される。プロジェクトに参加しないとだめなのだろうか。

まずBugster（http://bugs.opensolaris.org/）でバグの状況を調べる。たとえば「6740597  zfs fletcher-2 is losing its carries」は10-Fix Delivered (Fix available in build) なので、既に修正がリリースされている。修正が含まれるビルドはRelease Fixed欄に書いてあるsolaris_nevada(snv_114) である。

各ビルドのソースコードはON Download Archives（http://dlc.sun.com/osol/on/downloads/）にアーカイブされている。ビルド114はb114（http://dlc.sun.com/osol/on/downloads/b114/）である。

このビルドに含まれる変更はFull HTML Changelog (with files updated)に書いてある。たしかに6740597が入っていて、変更されたファイルのフルパスも分かる。

Issues Resolved:
    BUG/RFE: 6740597 zfs fletcher-2 is losing its carries
Files Changed:
    update:usr/src/grub/grub-0.97/stage2/zfs-include/zio.h
    update:usr/src/uts/common/fs/zfs/fletcher.c
    update:usr/src/uts/common/fs/zfs/sys/zio.h

ソースコードはON Source（http://dlc.sun.com/osol/on/downloads/b114/on-src.tar.bz2）である。これをダウンロードする。比較するために、一つ前のビルド（b113）のソースもダウンロードする。変更ファイルをdiffすると、ソースコードのどの部分が変更されたかが分かる。6740597では、usr/src/uts/common/fs/zfs/sys/zio.hの79行目が次のように変更されている。

b113

#define    ZIO_CHECKSUM_ON_VALUE    ZIO_CHECKSUM_FLETCHER_2

b114

#define    ZIO_CHECKSUM_ON_VALUE    ZIO_CHECKSUM_FLETCHER_4

つまり、チェックサムをONに設定したときのアルゴリズムをfletcher-2からfletcher-4に変更したということである。6740597はfletcher-2の脆弱性を指摘したもので、より強力なfletcher-4をデフォルトとすることで対処したようだ。このバグに関連するディスカッションはzfs-codeの次のスレッドである。

fletcher2/4 implementations fundamentally flawed
http://www.opensolaris.org/jive/thread.jspa?threadID=69655

Bugsterは私のアカウントだと、バグの最初のレポート内容しか出てこないが、アカウントの権限によってはその後の議論や修正コードへのリンクなどが見られるのかもしれない。

（注）Firefoxならmozilla-central（http://hg.mozilla.org/mozilla-central/summary）で修正履歴が分かるし、Bugzilla（https://bugzilla.mozilla.org/）の関連バグにもリンクされている。

ZFSインテントログ（ZIL）

Solaris ZFSのZILについて調べた。参考にしたのはSunのソフトウェアエンジニアのブログ記事である。

ZFS: The Lumberjack（ Neil Perrin's Weblog）
http://blogs.sun.com/perrin/#the_lumberjack

slog blog (or blogging on slogging)
http://blogs.sun.com/perrin/entry/slog_blog_or_blogging_on

The ZFS Intent Log（Neelakanth Nadgir's blog）
http://blogs.sun.com/realneel/entry/the_zfs_intent_log

ZFSの書き込みは、ディスク上で常に一貫性を保つように、DMUトランザクションとして扱われる（DMU = Data Management Unit）。DMUトランザクションは、全て反映されるか全く反映されないかのどちらか一方しかない（アトミック性）。

DMUトランザクションは主メモリ上でトランザクショングループにまとめられる。トランザクショングループがコミットされるのは、おおむね数秒間隔である。トランザクションをそのままディスクに反映せずにトランザクショングループにまとめるのは、書き込み性能を向上させるためである。

ファイルシステムをO_DSYNCでオープンしたり、fsync()を実行したりして同期書き込みを行うことがある。典型的なアプリケーションはデータベースである。同期書き込みは、更新データがstable storageに書き込まれたあとでアプリケーションにreturnすることを要請する。トランザクショングループがコミットされるまで待つと性能が悪化してしまう。これを解決するのがZFS Intent Log（ZIL、ZFSインテントログ）である。

ZILはディスク（HDDもしくはSSD）に置く。すなわちstable storageである。ZILに書き込まれるのは未コミットのトランザクションである。コミットされたトランザクションはZILから削除される。上記の同期書き込みのシナリオで考えると、トランザクションをZILに書き込んだ時点でstable storageに格納したと考えることができるので、すぐにアプリケーションにreturnしてよい。これにより同期書き込みの性能を向上させる。

64KB以下の書き込みは、データ自体がZILのログレコードに書き込まれる。64KBを超えるサイズの書き込みデータは、ディスクに同期したあとで、同期したデータへのポインタだけがログレコードに書き込まれる。

ZILは通常、メインプールの中に動的に割り当てられる。これを別デバイスに配置することができる（zpool add <pool> log <log devices>）。SSDのような高速デバイスに配置すると性能向上が期待できる。非ミラー構成のSSD ZILデバイスが故障したり、slogデバイスが満杯になったら、メインプールの領域を使う。

VMwareゲストがVMware Server 2のインベントリに追加できない

米国本社のエンジニアが作ったVMwareゲストが動かない。動かないどころか、インベントリに追加できない。私が使っているのはVMware Server 2.0.1（Windows版）である。面白いことにVMware Player 2.5.2では問題なくブートできる。

VMware Server 2のWeb管理画面に出てくるエラーメッセージはこうだ。

The selected virtual machine is not recognized on this system. The cause of this problem may be that the virtual machine's .vmx file is corrupted, or that the virtual machine version is newer than is recognized by the host. You can remove the virtual machine from the inventory if you believe that it is not recoverable.

Click the link below to remove the virtual machine from the inventory.

Remove Virtual Machine

To help diagnose the issue, you can check the virtual machine files at their last known location: "[standard] XXXX/XXXXX.vmx"

XXXXX.vmxを編集することで解決した。vmxファイルの先頭は次のようになっていた。

.encoding = "windows-1252"

私の環境で作ったvmxがすべてShift_JISになっていたので、次のように書き換えてみた。

.encoding = "Shift_JIS"

これでインベントリに追加できるようになり、ブートもできた。

legitimate

legitimateという単語を見聞きすることがときどきある。新しい言葉は、インプットするだけではなかなか身につかないので、アウトプットしてみよう。用例をいくつか拾ってみた。

ファームウェアやOSがハードエラーを誤検出することがある。誤検出は「false alert」あるいは「false positive」という。ウイルスの誤検出も同様である。反対に、どう考えても正真正銘のハードウェアエラーであるときは「legitimate」を使うとよい。以下は同僚のハードウェアエンジニアが書いたメールの一部である。

This looks like a legitimate memory issue.  I think this DIMM needs to be replaced.

legitimateの用法には、「まっとうな」「合法的な」という意味もある。以下の例文では、Webサイトへ悪意をもって送られた大量のリクエストによって、本来処理すべきリクエスト（legitimate incoming traffic）が処理できなくなることについて述べている。

somebody basically sends so many requests to your - phony requests, but requests - to your website that you spend all your bandwidth trying to handle them and can't handle legitimate incoming traffic.

最後の例文は、送信元IPアドレスを偽装したパケットなのか、正しく送られたパケットなのかを簡単には識別できないということについての話である。後者のことをlegitimate packetと言っている。right packetでもcorrect packetも、この文脈にはそぐわないだろう。

STEVE:  Ah, well, now, that's another good point, is the other thing that these packets are doing is that they're spoofing their source IP.  When a legitimate packet comes to a server or to an end-user, it identifies who sent it, that is, by IP address, and what its destination is.  The destination IP gets it to you.  The source IP is the IP to which you send the return traffic.  So the packet has to have both.  In these denial of service attacks, the source IP is being randomized on purpose so that you really don't know if it's legitimate or not.

（参考記事）
Security Now! Episode #8
http://www.grc.com/sn/sn-008.txt