図? NFSによるファイルの共有
情報学類 分散システム 2009年02月17日
筑波大学システム情報工学研究科
コンピュータサイエンス専攻, 電子・情報工学系
新城 靖
<yas@is.tsukuba.ac.jp>
このページは、次の URL にあります。
http://www.coins.tsukuba.ac.jp/~yas/coins/dsys-2008/2009-02-17
あるいは、次のページから手繰っていくこともできます。
http://www.coins.tsukuba.ac.jp/~yas/
http://www.cs.tsukuba.ac.jp/~yas/
NFS ( Network File System ) は, Sun Microsystems 社が 開発したネットワーク・ファイル・システムの名前(固有名詞, 商標)。
その他のネットワーク・ファイル・システム(用のプロトコル)
NFSを使うと, ネットワークを通じて別のコンピュータ上のファイルシステム
の一部分を, ローカルディスク上にあるファイルシステムと同じように, 自分
のファイルシステムの木に
マウント(mount)
できる。
図? NFSによるファイルの共有
相互に参照し合える。
nfsd というプログラムが
動いているように見える(
ps コマンドで表示される)
が、それは普通のプロセスではない。
/usr/include/rpcsvc/nfs_prot.x
表? NFSで使われているRPCの手続き
| 手続き名 | 意味 | 関連するコマンド、システムコール |
|---|---|---|
| null() | 何もしない | rpcinfo -u hostname nfs コマンド |
| getattr() | 属性の読み出し | ls -l コマンド, stat システムコール , open システムコール |
| setattr() | 属性の設定 | chmod , chown コマンド |
| lookup() | ファイルの検索 | open システムコール |
| readlink() | シンボリックリンクの読み出し | ls -l コマンド, readlink システムコール |
| read() | ファイルの読み出し | read システムコール |
| write() | ファイルの書き込み | write システムコール |
| create() | ファイルの作成 | creat システムコール, open システムコール |
| remove() | ハードリンクの削除 | rm コマンド, unlink システムコール |
| rename() | ファイル名前の変更 | mv コマンド, rename システムコール |
| link() | ハードリンクの作成 | ln コマンド, link システムコール |
| symlink() | シンボリックリンクの作成 | ln -s コマンド, symlink システムコール |
| mkdir() | ディレクトリの作成 | mkdir コマンド |
| rmdir() | ディレクトリの削除 | rmdir コマンド |
| readdir() | ディレクトリの読み出し | ls コマンド |
| statfs() | ファイルシステムの利用状況 | df コマンド, statfs システムコール |
| commit()* | ディスクへの書き込み | fsync システムコール |
| access()* | アクセス権のチェック | access システムコール |
NFS でファイルやディレクトリを区別するための識別子。32バイト。
const NFS_FHSIZE = 32;
...
/*
* File access handle
*/
struct nfs_fh {
opaque data[NFS_FHSIZE];
};
一番最初のNFSファイル・ハンドルをどうやって入手するか。
| 手続き名 | 意味 | 関連するコマンド、 システムコール |
|---|---|---|
| null() | 何もしない | rpcinfo -u hostname mount コマンド |
| mnt() | NFSファイルハンドルを返す | mount コマンド |
| dump() | マウント一覧表 | showmount hostname コマンド |
| umnt() | アンマウント | umount コマンド |
| umntall() | 全アンマウント | umount -h hostname コマンド |
| export() | アクセス可能なディレクトリのリストを返す |
2.2.5. Look Up File Name
diropres
NFSPROC_LOOKUP(diropargs) = 4;
If the reply "status" is NFS_OK, then the reply "file" and reply
"attributes" are the file handle and attributes for the file "name"
in the directory given by "dir" in the argument.
2.3.10. diropargs
struct diropargs {
fhandle dir;
filename name;
};
The "diropargs" structure is used in directory operations. The
"fhandle" "dir" is the directory in which to find the file "name".
A directory operation is one in which the directory is affected.
2.3.11. diropres
union diropres switch (stat status) {
case NFS_OK:
struct {
fhandle file;
fattr attributes;
} diropok;
default:
void;
};
The results of a directory operation are returned in a "diropres"
structure. If the call succeeded, a new file handle "file" and
the "attributes" associated with that file are returned along with
the "status".
2.2.7. Read From File
struct readargs {
fhandle file;
unsigned offset;
unsigned count;
unsigned totalcount;
};
union readres switch (stat status) {
case NFS_OK:
fattr attributes;
nfsdata data;
default:
void;
};
readres
NFSPROC_READ(readargs) = 6;
Returns up to "count" bytes of "data" from the file given by "file",
starting at "offset" bytes from the beginning of the file. The first
byte of the file is at offset zero. The file attributes after the
read takes place are returned in "attributes".
Notes: The argument "totalcount" is unused, and is removed in the
next protocol revision.
2.2.9. Write to File
struct writeargs {
fhandle file;
unsigned beginoffset;
unsigned offset;
unsigned totalcount;
nfsdata data;
};
attrstat
NFSPROC_WRITE(writeargs) = 8;
Writes "data" beginning "offset" bytes from the beginning of "file".
The first byte of the file is at offset zero. If the reply "status"
is NFS_OK, then the reply "attributes" contains the attributes of the
file after the write has completed. The write operation is atomic.
Data from this "WRITE" will not be mixed with data from another
client's "WRITE".
Notes: The arguments "beginoffset" and "totalcount" are ignored and
are removed in the next protocol revision.
RPC のようにコネクションが作られない通信サービスを使う時に冪等や無状態 といった性質を実現する時に必要になる技術。
例：NFSでのディレクトリの読み込み手続き nfsproc_readdir() で、１回の RPC で全部のデータを返せないことが起きる。 ディレクトリのどの位置まで読み込んだかを 示す中間状態を クッキー(cookie) という形でクライアントに返す。
クライアントは、次の RPC の呼び出しで、 前回受けとった応答の中のクッキーを、サーバへの要求に含めて送す。
const NFS_COOKIESIZE = 4; typedef opaque nfscookie[NFS_COOKIESIZE];
2.2.17. Read From Directory
struct readdirargs {
fhandle dir;
nfscookie cookie;
unsigned count;
};
struct entry {
unsigned fileid;
filename name;
nfscookie cookie;
entry *nextentry;
};
union readdirres switch (stat status) {
case NFS_OK:
struct {
entry *entries;
bool eof;
} readdirok;
default:
void;
};
readdirres
NFSPROC_READDIR (readdirargs) = 16;
Returns a variable number of directory entries, with a total size of
up to "count" bytes, from the directory given by "dir". If the
returned value of "status" is NFS_OK, then it is followed by a
variable number of "entry"s. Each "entry" contains a "fileid" which
consists of a unique number to identify the file within a filesystem,
the "name" of the file, and a "cookie" which is an opaque pointer to
the next entry in the directory. The cookie is used in the next
READDIR call to get more entries starting at a given point in the
directory. The special cookie zero (all bits zero) can be used to
get the entries starting at the beginning of the directory. The
"fileid" field should be the same number as the "fileid" in the the
attributes of the file. (See section "2.3.5. fattr" under "Basic
Data Types".) The "eof" flag has a value of TRUE if there are no
more entries in the directory.
nfsproc_readdir() で、１回目と２回目の RPC の間にディレクトリの内容が 更新された場合、どのような結果になるのか不明。
commit() という手続きが追加。
それまでに行われた書き込みをディスクに行うように指示できる。
(NFS v2 では、write で必ずディスクに書き込む。)
昔の名前は、 SMB (Server Message Block) プロトコル。 Samba は、 CIFS/SMB を、Unix 系のオペレーティング・システムで実現したプログラム。
Samba の利用法
ＷＷＷ（World Wide Web）では、１回のデータ転送ごとに通信路が切断される ので、通常はＷＷＷのブラウザ（クライアント）とＷＷＷサーバの間では、途 中経過を保持することができない。
途中経過を保存したい時：
ＷＷＷで途中経過を保存するためには、cookie が使われる。
4. EXAMPLES
4.1 Example 1
Most detail of request and response headers has been omitted. Assume
the user agent has no stored cookies.
1. User Agent -> Server
POST /acme/login HTTP/1.1
[form data]
User identifies self via a form.
2. Server -> User Agent
HTTP/1.1 200 OK
Set-Cookie2: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"
Cookie reflects user's identity.
3. User Agent -> Server
POST /acme/pickitem HTTP/1.1
Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
[form data]
User selects an item for "shopping basket".
4. Server -> User Agent
HTTP/1.1 200 OK
Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
Path="/acme"
Shopping basket contains an item.
5. User Agent -> Server
POST /acme/shipping HTTP/1.1
Cookie: $Version="1";
Customer="WILE_E_COYOTE"; $Path="/acme";
Part_Number="Rocket_Launcher_0001"; $Path="/acme"
[form data]
User selects shipping method from form.
6. Server -> User Agent
HTTP/1.1 200 OK
Set-Cookie2: Shipping="FedEx"; Version="1"; Path="/acme"
New cookie reflects shipping method.
7. User Agent -> Server
POST /acme/process HTTP/1.1
Cookie: $Version="1";
Customer="WILE_E_COYOTE"; $Path="/acme";
Part_Number="Rocket_Launcher_0001"; $Path="/acme";
Shipping="FedEx"; $Path="/acme"
[form data]
User chooses to process order.
8. Server -> User Agent
HTTP/1.1 200 OK
Transaction is complete.
The user agent makes a series of requests on the origin server, after
each of which it receives a new cookie. All the cookies have the
same Path attribute and (default) domain. Because the request-URIs
all path-match /acme, the Path attribute of each cookie, each request
contains all the cookies received so far.