.\"
.\" Copyright (c) 1992, 1993, 1994
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" This code is derived from software donated to Berkeley by
.\" John Heidemann of the UCLA Ficus project.
.\"
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"     @(#)mount_null.8	8.6 (Berkeley) 5/1/95
.\" %FreeBSD: src/sbin/mount_null/mount_null.8,v 1.10.2.1 1999/08/29 15:14:29 peter Exp %
.\" jpman %Id: mount_null.8,v 1.2 1997/03/31 13:38:01 horikawa Stab %
.\"
.Dd May 1, 1995
.Dt MOUNT_NULL 8
.Os BSD 4.4
.Sh 名称
.Nm mount_null
.Nd ループバックファイルシステムサブツリーをマウントする;
何もしない(null)ファイルシステム層の利用のデモ
.Sh 書式
.Nm mount_null
.Op Fl o Ar options
.Ar target
.Ar mount_point
.Pp
.Sh 解説
.Nm
は、null 層を作ります。これは、
ファイルシステムの名前空間の部分木を、グローバルなファイルシステムの名前空間
の別の場所にエイリアスします。
これにより、既存のファイルとディレクトリが別のパス名にてアクセス可能
となります。
.Pp
ファイルシステムの仮想的コピーとシンボリックリンクとの第 1 の違いは、
.Xr getcwd 3
関数が仮想コピーでは正しく動作する点と、
別のファイルシステムを仮想コピー上にマウントしてもオリジナルには影響がない点
です。
.Xr stat 2
は、仮想コピーに対して別のデバイス番号が返しますが、
別の側面においてはオリジナルとの区別はつきません。
.Pp
歴史的な
ループバックファイルシステムと異なるのは、次の2つの点です: 1つは、ファイル
システムのスタック化可能層(stackable layers)という技術を使って
実装されている点、もう1つはディレクトリの vnode だけでなく、
すべての下位層の vnode の上に
``null-node''が積み重なっているという点です。
.Pp
オプションは以下のものがあります:
.Bl -tag -width indent
.It Fl o
.Fl o
のあとに、オプション文字列をコンマで区切って指定すること
ができます。指定可能なオプションとその意味は
.Xr mount 8
を参照してください。
.El
.Pp
この null 層は2つの目的を持っています。1つは、何もしない層
を提供することでファイルシステムの層の構築のデモを示すことです(実際には
何も行わないというわけではなく、
ループバックファイルシステムが提供することはすべて行います)。
もう1つはプロトタイプ層を提供することで
す。層のフレームワークとして必要なことはすべて提供しているので、
ここから新しいファイルシステム層を簡単に作り出すことができます。
.Pp
このマニュアルの以下の部分では、新しいファイルシステム層を構築するための
基礎として null 層を調べます。
.\"
.\"
.Sh 新しい null 層の例示
新しい null 層は
.Xr mount_null 8
で作られます。
.Xr mount_null 8
は
2つの引数をとります。
1つは下位層の vfs のパス名(target-pn)で、
もう1つは null 層が現れる名前空間内のパス名(mount-point-pn)です。
null 層が適切な場所に置かれた後、
目的のディレクトリ階層(target-pn)の中身が
マウント先(mount-point-pn)にエイリアスされます。
.\"
.\"
.Sh null 層の操作
null 層は最小のファイルシステム層であり、
すべての操作を下位層に処理させるためにバイパスするだけです。
ほとんどすべてのvnodeに対する操作はパスすることですが、
その動作のほとんどはバイパスルーチンに集中します。
.Pp
バイパスルーチンは下位層における任意の vnode に対する操作を受け付けます。
まず、vnodeに対する操作の引数を検査し、
null-node を下位層において等価となるものに置き換えることから始めます。
次に、下位層の操作を起動します。
最後に、引数中の null-node を置き換えます。
もしその操作によってvnodeが返ってきたら、
その返ってきたvnodeの上に null-node を積みます。
.Pp
ほとんどの操作をバイパスしますが、
.Em vop_getattr , 
.Em vop_inactive ,
.Em vop_reclaim ,
や
.Em vop_print
はバイパスしません。
.Em vop_getattr
は戻り値の fsid を替えなければなりません。
.Em vop_inactive
と vop_reclaim は、null 層特有のデータを解放するためにバイパスしません。
.Em vop_print
は過度のデバッグ情報を避けるためにバイパスしません。
.\"
.\"
.Sh vnodeスタックの概説
マウントは null 層を下位層に関連づけます。
その結果 2 つの VFS が積み重なります。
vnode スタックはファイルがアクセスされるたびに必要に応じて作成されます。
.Pp
最初のマウントでは新しい null 層の根として単一の vnode スタックを作ります。
他のすべての vnode スタックは根の vnode スタックや他の null vnode スタックの
操作の結果として作られます。
.Pp
vnode を返す操作の結果として新しい vnode スタックが生まれます。
バイパスルーチンは、呼出し側に vnode を返す前に新しい vnode の上に null-node
を積みます。
.Pp
例えば、null 層を以下のようにマウントする例を想像します。
.Bd -literal -offset indent
mount_null /usr/include /dev/layer/null
.Ed
.Pa /dev/layer/null
にチェンジディレクトリすると、根の null-node (null 層をマウントした時
に作られたもの) が割り当てられます。
ここで
.Pa sys
をオープンすることを考えてみます。
vop_lookup は根の null-node で行なわれます。
この操作は下位層にバイパスされ、下位層が
UFS の
.Pa sys
を表す vnode を返します。
それから null_bypass は
UFS
.Pa sys
にエイリアスする null-node を構築し、呼出元にこれを返します。
null-node
.Pa sys
に対する以降の操作で他のvnodeスタックを構築する時には
この処理が繰り返されます。
.\"
.\"
.Sh 他のファイルシステム層の作成
新しいファイルシステム層を構築する一番簡単な方法は、
null 層のコピーを作り、すべてのファイル、変数の名前を付け直し、
そしてそのコピーを変更することです。
すべての変数の名前を変えるのには 
.Xr sed 1
が良く使われます。
.Pp
umap 層は null 層の子孫の 1 例です。
.\"
.\"
.Sh 下位層の操作の起動
操作が完全にはバイパスできない時に
下位層にある操作を起動するための方法が 2 つあります。
それぞれの方法は違った状況に対して適切に使われます。
両方の場合とも、
その操作の引数を下位層のために正しく作るのはエイリアスする層の責任であり、
vnode 引数を下位層にマッピングします。
.Pp
最初の方法はエイリアスする層のバイパスルーチンを呼ぶことです。
この方法は、下位層で現在扱われている操作を起動したい時に最も適しています。
これはバイパスルーチンがすでにマッピングされているという利点があります。
この例として、
.Em null_getattrs
が null 層にあります。
.Pp
2 つ目の方法は、
.Em VOP_OPERATIONNAME
インタフェースを用いて下位層のvnodeの操作を直接起動することです。
この方法の利点は、下位層の任意の操作を起動するのが簡単ということにあります。
欠点は、vnode 引数は手動でマッピングされなければならないことです。
.\"
.\"
.Sh 関連項目
.Xr mount 8
.sp
UCLA Technical Report CSD-910056,
.Em "Stackable Layers: an Architecture for File System Development" .
.Sh バグ

本ファイルシステムタイプは、まだ完全にはサポートされていません
(注: 機能しないということです) し、
実際のところ使用するとシステム上のデータを破壊するかもしれません。
自己責任において使用してください。
猛犬注意。濡れていて滑ります。

危険性を減らすためには、このコードもまた所有者を必要としています -
真面目なハッカーの方はメールを hackers@freebsd.org に送って
引き継ぎの意思を宣言してください。

.Sh 歴史
.Nm
は、
.Bx 4.4
から登場しました。