オートマウント/オートプレイの解除

対象となるドライブが autofs, supermount, subfs/submount, magicdev などのLinux用^(*)のオートマウント/オートプレイ機構の制御下にある場合、必ずそれを解除してください。 解除の方法はそれぞれのドキュメント (google とか :-) を参照してください。

解除できなければ書込失敗は必至で、コースターを量産するはめになります。 少なくとも書き込み中だけでも解除しておく必要があります。

(*) dvd+rw-tools は Solarisのボリュームマネージャと IRIX の mediad をサポートしており、それらを解除する必要はありません。

ハードウェア互換性ノートの注意すべき点やベンダ固有の問題を参照しておいてください。 このような注意書きは本来チュートリアルの最後に書くべきですが、とても重要なことなのであえてここに書きました。

カーネル 2.4.x で IDE ドライブを用いる場合の注意

次のいずれかの方法で ide-scsi エミュレーションを経由させることになります。

• カーネルパラメータに “hdX=ide-scsi” を記述する
• /etc/modules.conf に次のような行を追加する

  options ide-cd ignore=hdX
pre-install sg modprobe ide-scsi
pre-install sr_mod modprobe ide-scsi
pre-install ide-scsi modprobe ide-cd

これにより、hdX はide-scsi 経由となるため、 /dev/scdN としてのみ使うことになります。 /dev/hdX は使えません^(*)。

(*) hdparm -d ['0|1'] /dev/hdX などのように使う場合を除きます。多くの NEC [ベースの] ドライブの利用者から、DVD 書込み中にシステムがクラッシュすることが報告されており、 hdparm を使って DMA を無効化することで解消するとのことです。この問題は特定の IDE チップセットの問題だと思います。

外付けドライブを使う場合の注意

まずそれが CD-ROM ドライブとして動作していることが重要です。 私自身、USB や IEEE1394/Firewire 接続の外部記憶装置の類いを使ったことがありませんから、その方法は各自で調べてください。

そのドライブが CD-ROM と CD-R['W'] ドライブとしてきちんと使えてさえいれば、 dvd+rw-tools を使った DVD 書込みでも問題が起こることはないはずです。 これまでのところUSB接続ドライブは問題なく使えるようです。

Firewire 接続ドライブについては、カーネルバージョン 2.4.18 では悲惨な結果に終わることが報告されています。 ただこのケースでは CD-R メディアの書込みも失敗していますから DVD+RW 固有の問題ではなく Firewire に起因する問題だったようで、カーネルバージョン 2.4.19 で解消したとのことです。

カーネルバージョンが 2.4.19 か .20 の場合の注意

ここにある drivers/scsi/sg.c のパッチを当てることを検討してください。 「当ててください」ではなく、「当てることを検討してください」と書いたのは次の理由からです。

• dvd+rw-tools は SG_IO インターフェースを用いていないため、このバグの影響は受けません。 cdrecord が影響を受けるのです。
• とはいえ、私自身は未だ cdrecord でこの問題に遭遇していません (多分私が使った時にはカーネルがたまたまバッファの整合性をうまく保っていたのだと思います)。 VMware では悲惨な目に会いましたが。

dvd+rw-tools バージョン 5.6 で SG_IO パススルーをサポートしました。 これは Linux バージョン 2.5.43 以上に実装されているものです。 ブロックデバイス /dev/hdX に対し、 SG_IO ioctl を直接発行することで汎用 SCSI インターフェースをバイパスさせることができます。

ただこれには暫定パッチ #1 と #2 が必要です (後者は 2.5.69-75 用です。第1の問題が見つかったのは .71 の時、第2の問題が見つかったのは 2.6 が出る直前の .75-bk3 の時です）。

カーネルバージョン 2.6 ではこの新しいインターフェースを使うことで ide-scsi レイヤを不要とし“彼らの正式な計画^TM”によればそれを取り去ってしまうことになっています。 私は正直この考えには賛同できません。 /dev/sg* にこだわっているわけではありません。 つまり、 ide-scsi を残して /dev/scdN による SG_IO パススルーを使うのが私の好みです :-)

dvd+rw-tools を Linux カーネル 2.6.8 で使おうとする場合は注意が必要です。 dvd+rw-tools のバージョンを 5.21.x 以上とし、そのツリーに含まれる実行可能ファイルに set-root-uid フラグを与えるという作業が必要になります。 ただ私のお奨めはこのカーネルバージョンを使わないことです。 なおカーネル 2.6.>8 ではdvd+rw-tools のバージョンとして 5.21.x であることが必須です。これに伴い dvd+rw-booktype ユーティリティには set-root-uid 権限が必要になります。 この対応はまだ最終的なものではなく、またこのユーティリティは限られたドライブでしか動作しないことから、この権限付与は dvd+rw-booktype インストール時に行われないようにしてあります。 このようなセキュリティ上の問題を引き起こす可能性のある作業は、ユーザの手に委ねたいと思います。

ダウンロード，アンパック，およびコンパイルをする上での注意

.spec ファイルと Makefile 等を含む .tar.gz アーカイブをダウンロードしてください。 C と C++ がインストールされている必要があります。 ダウンロードカタログにあるソースコードファイルは主にオンラインで参照できるように置いてあるものです(例えば改定来歴を参照するなどのため)。

もしお使いの Linux カーネルが複数の ABI (Application Binary Interface?) をサポートするものなら(例えば Linux-x86_64 では 32-bit の i386 バイナリを実行できますし、 Linux-sparc64 では 32-bit Linux-sparc アプリケーションを実行できるなど)、ネイティブ 64-bit ABI としてコンパイルすることを忘れないでください(普通は 'make TARGET_ARCH=-m64' とすれば良いはずです)。

問題なのは、64-bit カーネルは32-bit アプリケーションから渡された ioctl 構造体を変換しなければならず、 dvd+rw-tools から CDROM_SEND_PACKET ioctl が呼ばれる度にそのような無駄なことが行われるということです。

第1世代のドライブを使う際の注意

第1世代のドライブとは Ricoh の MP5120A とその派生機のことです。 詳しくは dvdplusrw.org の世代リストを参照してください。 このドライブを使う場合はファームウェアのアップグレードを検討すべきです (ファームウェアの最新バージョンについては Ricoh のホームページを参照)。

バグ修正内容は不明ですが、少なくとも、大量の小さなファイルを読み込むときに頻発していた“ランダム・ポジショニング・エラー”は、ファームウェアをバージョン 1.34 にアップグレードすることで解消されました。 バージョン 1.34 では Verbatim 製メディアのサポートが追加され、1.37 からは Memorex がサポートされたはずです。 バージョン 1.37 では他の DVD-ROM ドライブとの互換性を向上するためのベンダ固有のコマンドが追加されたとのことです (詳細は技術解説を参照)。

Ricoh の MP5125A とその派生機は第2世代機にあたりますが、DVD＋R (DVD+RW ではない) の書込み中にシステムがロックしてしまうことが多くのユーザから報告されています。 私自身はそれを経験していないのですが、ファームウェアのアップグレードが対策として有効だとのことです。

ですから第2世代機であってもファームウェアのアップグレードを検討すべきでしょう。 そもそも第2世代機で4倍速メディアへの書込みをするにはファームウェアアップグレードが必須です。 2.4倍速メディアでは問題なくても4倍速メディアを使ったとたんに悲惨な目に会います。

市場では常に新しいメディアが出てきますから、いつもファームウェアの更新に目を光らせておく必要があります。 既に第1世代/第2世代というような括りではなく、ベンダごとの動向に注目しなければなりません。

ただし HP ユーザは特別な注意が必要です。HP はファームウェア更新をウェブ上で行いません。代わりに Windows の自動アップデートを使い、FTPサイトにある適切なファイルを自動的にダウンロードして更新するようになりました。 つまりこれを読んでいない人は更新を見逃してしまうわけです。

DVD+RW メディアのフォーマッティングについて

未使用の DVD+RW メディアは、使う前にフォーマッティングする必要があります。 くどいようですが、フォーマッティングが必要なのは DVD+RW メディアが未使用の場合に限ります。 growisofs のバージョン 5.10 からは、メディアがブランクであることを自動的に検出して初期フォーマッティングを行うようになりました。 同じ事は dvd+rw-format の引数に /dev/scd0 のようなデバイス名を明示的に与えることで実現できます。

DVD+RW では初期フォーマッティングを高速に行うため (1分未満)、メディアの一部分のみがフォーマットされます。 これは dvd+rw-format の進捗表示を見ればわかります。 最後の数値表示はファームウェアによって異なりますが、1.6% 未満の値になるはずです。 この容量しか使えないというわけではないので心配しないでください。 データを追加する際に自動的にフォーマッティングもされます。

そうそう、DVD の公称記録容量である 4.7GB は営業用単位です。 つまりこの GB は 1000³であって 1024³ではありません。

10〜20 回程度の再フォーマットでそのメディアが使えなくなることがあります。 それは大抵メディアの欠陥ではなく、ドライブのファームウェアの問題です。 少なくとも他社製ドライブではそのメディアが問題なく使えるケースがほとんどだからです。

いずれにせよ再フォーマットはお奨めできません。 注意したいのは DVD+RW の再フォーマットはメディアのブランキング (データ消去) の意味をもたないということです。 プライバシー保護などの目的でデータ消去を行いたいのなら、明示的に 'growisofs -Z /dev/scdN=/dev/zero' としてください。 単に他のデータで上書きするだけでもOKです。 再フォーマットは必要ありません。

一方 DVD+R メディアはフォーマッティング不要で箱から出してすぐに使えます。 ただし前述の第1世代のドライブでは DVD+R は使えません。

growisofs での書込みについて

growisofs の使い方についてのマニュアルは実はほとんど必要ないのです。

訳者注： 私が翻訳した growisofs(1m) の man page はここにあります >>

growisofs は (1)コマンドラインの引数をそのまま mkisofs に渡し、(2)その出力をメディア上にダンプします。ですから前半(1)の処理については mkisofs の man page と関連するドキュメントを見れば良いわけです(マルチセッションに関する部分についても)。 後半(2)の意味するところは、単に、ISO イメージが標準出力に現れることはなく、テンポラリディスクスペースを気にする必要もないということです。

growisofs が mkisofs と異なる点は次の通りです。

• -o オプションは使いません。
• -C オプションは使わないこと。 growisofsがこのオプションを自動生成します。
• -Z オプションは最初のセッションの書込みで使います。 これは 'mkisofs | dd of=/dev/scd0' に相当します。

mkisofs の使用法の[マルチセッション]でのマスタリングを除いた部分は growisofs でも同様です。 例えば最初のセッションを書き込む場合、mkisofs の場合と同様に、

最初のセッションでは：

growisofs -Z /dev/scd0 -R -J /some/files

次のセッションでは：

growisofs -M /dev/scd0 -R -J /more/files

とします。 ただし少なくとも mkisofs のバージョン1.14 (以上) が $PATH で示されるディレクトリに存在していることが前提です。 (mkisofs 1.14 は cdtools 1.10 に含まれます)

常に同じディレクトリ/ファイルを指定するような使い方、つまり growisofs をマルチセッションによる増分バックアップに利用しようとするなら、mkisofs 2.0〜2.01 (のみ) に対応した '-old-root' エクステンションが便利でしょう。 これは Patrick Ohly が発案・実装したもので、セッションを別のディレクトリとして継ぎ足していくようにするものです。各増分ディレクトリは、更新されたファイルと直前の増分ディレクトリへの参照をもつ形で作られます。 これによりリストアにおける世代選択が可能となると共に増分間の比較も容易になります。

マルチセッションよりもマルチボリュームをサポートして欲しいとの要望もありますが、growisofsはあくまでDVD書込みプログラムであり、そのような機能をサポートするつもりはありません。代わりにscdbackupやshuntなどのフロントエンドの利用をお勧めします。

growisofs のバージョン 3.3 以上では -Z オプションの特殊な使い方として、任意のイメージから DVD を焼くことができます。その魔法のコマンドは、

growisofs -Z /dev/scd0=image.iso

です。 ここで image.iso はファイルシステム上の任意のオブジェクト、すなわちファイル，名前付きパイプ，そしてデバイスエントリなどです。 growisofs という名前らしからぬ使い方ですね。 だって何も“grow”しませんし。もっと「らしからぬ」使い方だってできますよ:-)。 例えばあるプログラムから出力されるイメージを使って DVD を焼きたいのなら、

dumpsomething | growisofs -Z /dev/scd0=/dev/fd/0

なんてこともできます。

DVD±Rに関する制約

• 「-Z オプションは1回だけ」ということは言うまでもありませんね :-)
• DVD+RW と違って DVD±R メディアにはマルチセッションという概念があります。 しかし古いドライブの中には2番目以降のセッションが読めないものがあります。 DVD-R マルチボーダー再生をサポートするドライブは稀で、DVD+R のマルチセッションに至ってはほとんどサポートされていないのが実情だからです。 つまり異なる領域に書かれた内容を読めるのは、あなたの周りでは多分それを焼いたドライブだけということです。
• ドライブがマルチセッションを検出できても、Linux カーネル['2.4']ではその情報を読み出せないことがあります:-(。 現状ではとりあえず 'rmmod sr_mod' のようにドライバを再ロードしながら使うしかありません。
• Linuxカーネル2.6において、最終セッションが2.2GBを越えて書き込まれたマルチセッションメディアのマウントに失敗する経験がある方がいるかもしれません。この問題はとりあえず、ドライブをカーネル2.4の場合と同様にide-scsi経由で使うことで回避できます。カーネル2.6ではide-scsiは廃止されたはずですが実際は問題なく動作します。(私自身まだ使っています)
• DVD±R のマルチセッションを使う場合、 mkisofs として cdrtools-2.0 以降に含まれるものを使うか、ここにあるパッチを当てるかしなければなりません。
• 2層DVD+Rメディア(DVD+R DL)の書込みには対応できていません。現状ではメディアの1/2未満の容量までしか書込みできません。現状の2層メディアの価格を考慮すれば当面の間は1層メディアを利用することをお勧めします。

訳者注： 実は2層DVD+Rメディア(DVR+R DL)のサポートは、growisofsバージョン5.20から試験的に行われています。詳細は[ここ]を参照してください。

繰返しになりますが、4.7GB の“GB”は営業用単位です。 つまりこの GB は 1000³であって 1024³ではありません。 本来の GB (ギガバイト) でいえば、 DVD±R['W'] の容量は 4.4GB 未満となります。

初期の growisofs では、書き込もうとするデータセットのサイズとメディアの容量をチェックしていなかったため、“overburn”とならないように気をつける必要がありました。 growisofs バージョン 5.2 からは、書込み前に“overburn”になるかどうかをチェックし、そうなる場合は書込みを開始しません。ただし -overburn によってこのチェックを無効にすることもできます。

カーネルパッチについて

これまでの説明で growisofs に満足でそうな人は、カーネル 2.4 へのパッチは不要ですから次の章に進んでください。 まだ続きを読もうとしている人は、パッチをダウンロードして適用し、カーネルやモジュールをリビルドして再インストールしてください (カーネル、またはモジュール cdrom.o と sr_mod.o のどちらか)。

具体的な方法は聞かないでください。 パッチの対象が SCSI CD-ROM モジュールであることはお気付きのはずです。 つまり IDE ドライブを ide-scsi 経由で動作させるということです。

試しにフォーマッティングされた DVD+RW をドライブに挿入し、 'dd if=/dev/scdN count=0' としてアクセスすることで“srN: mmc-3 profile: 1Ah”のような行がカーネルログに現れることを確認してみてください。 これが確認できたら、 'mkisofs -pad . | dd of=/dev/scdN obs=32k' とか 'mke2fs -b 2048 /dev/scdN' のようなことができるはずです。 この場合のカーネルログは“srN: dirty DVD+RW media.”のようになるはずです。

Linux 2.6 ではカーネルによって DVD+RW がサポートされることになっています (DVD+MRW kernel support といいます)。 これはドライブメーカに対して DVD+MRW 対応製品を早く出せと言っているようなものです。

何を言いたいのかというと、そんな約束をしたにもかかわらずメーカはそのようなドライブを未だ製品化していないということです。 2003年4月1日時点の最新モデルである Ricoh MP5240A, Philips DVDRW416K や BenQ DW400A などでも Mt.Rainier規格/EasyWrite はサポートされていません。 今後ファームウェアのアップグレードでサポートされる可能性はありますが。

いずれにせよ、プロジェクトの目標は、DVD+['M']RW 対応ドライブのサポートのみならず、古い DVD-ROM ドライブでの DVD+MRW メディアの再生までをサポートすることです (OS によってメディアの欠陥リストがきちんと読めればの話ですが)。

---

訳者注

Mt.Rainier規格，EasyWrite

Philips 社を中心とした企業団体 Mt.Rainier により定められた次世代パケットライティングに関する規格。 ファームウェアでのメディアの不良セクタ管理や、バックグラウンドフォーマッティングもサポートする。 EasyWrite は Philips 社の登録商標で、Mt.Rainier 規格準拠ドライブに与えるロゴ。

DVD+MRW

Mt.Rainier 規格に準拠した DVD+RW のこと。

ファイルシステムに関する注意

カーネルによって、任意のファイルシステムの構築・マウントが可能となればすぐにでも利用したくなるかもしれませんが、その前に注意しなければならないことがあります。

ご存知のように DVD+RW メディアは1000回程度の再書込みにしか耐えません。 問題は汎用のファイルシステムでは読込みが発生するたび(または一定量の読込みが発生するたび)に、対応する i-node の更新が行われる、つまり書込みが行われるということです。

仮にメディアを /mnt/dvd にマウントし、1日10回の参照を行うとします。 するとそのマウントポイント、つまりメディアの寿命は100日程度になります。かなり短いですよね。 では DVD+RW メディアをマウントする際 noatime オプションを使うか、いっそのこと普段は read-only モードでマウントして使いますか？ その場合はマウント/アンマウントの頻度が高くなりますよね。 実は read-write モードでのマウントを行う場合もスーパーブロックの更新が行われるため、やはり書込みが発生します。 ですから1日3回の頻度でこれをやったとしても、寿命は1年程度になってしまいます ( supermount があなたの部署の予算をすぐに使い果たしてくれるでしょう)。

ファームウェア (つまり Mt.Rainier) かファイルシステムレベルで欠陥管理ができれば寿命を延ばすことができるでしょう。 しかし本来、一度マウントされたらデータの記録以外での書き込みは行われるべきではないのです。

Linux UDF ではこれが実現しそうですです (UDF についてのみですが)。 この要望はすでに上げられ、必要な議論は行われているのですが未だ日の目をみません。 残念ながら UDF サポートはデフォルトで無効になっており、これを有効にするには自分でカーネルやモジュールをリビルドすることになります。 あるいは (これが私の好みですが) SourceForge からコードをもってきてモジュールを単独でビルドします。もちろん udftools のコードも入手してビルドする必要があります。 いったんこれを行えば、UDF を次のように使えるようになります。

mkudffs --spartable=2 --media-type=cdrw /dev/scdN
mount -o rw,noatime /dev/scdN /mnt/cdrom


上のmkudffsコマンドラインのオプションはUDFメインテナーのBen Fennemaのお奨めです。

パフォーマンスの最適化について

この段落はカーネルパッチを施した場合にのみ有効です。

私は過去に「最高のパフォーマンスを得るためには obs=32k とすること」と書いたことがあります。 しかしこれは誤りでした。 ドライバのブロックデバイスレイヤーでストリームの再構成が行われますから、'>/dev/scd0' をわざわざ '|dd of=/dev/scd0 obs=32k' としたところで違いはありません。

いずれにせよ /dev/scd0 へのデータのダンプは、ブロックバッファキャッシュを経由するために VM サブシステムに大きな負荷を掛けることになります。 この負荷を最小限としシステム全体のパフォーマンスを改善するには、'raw /dev/raw/raw1 /dev/scd0' などとして cdrom デバイスを raw デバイスにバインドしてしまうことが有効と考えられ、growisofs はこれを自動的に行います。

しかしこれで obs=32k が大きな意味をもつわけではありません。 実は dd (や tar コマンドなど) を使ってみるとわかるのですが、バッファのアライメントが期待したように行われません。 この対策をやってみたのがこれです。興味のある人はいじってみてください。