FUSE-memoryfs
引き続きFUSEをいじっている私です。
今日のところはこんな感じで↓
fuseを使用してmemoryfsを作った際の疑問
=>誰がメモリをつかむのだ？
=>ディスクサイズは可変なのか？
これらの疑問を解消すべく、ターミナルを叩いてみる。
1.起動前
[skobayas@localhost ~]$ ps alx|head -1 && ps alx| grep fuse
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 500 2261 1 20 0 35652 2180 futex_ Ssl ? 0:00 /usr/libexec//gvfs-fuse-daemon /home/skobayas/.gvfs
0 500 21934 2584 20 0 5308 816 pipe_w S+ pts/1 0:00 grep fuse
2.起動直後
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 500 2261 1 20 0 35652 2180 futex_ Ssl ? 0:00 /usr/libexec//gvfs-fuse-daemon /home/skobayas/.gvfs
0 500 21935 2510 20 0 28216 3824 futex_ Sl+ pts/0 0:00 python example.py /tmp/fuse
0 500 21956 2584 20 0 5308 812 pipe_w S+ pts/1 0:00 grep fuse
3.手始めに4Mのファイル（1ケ）をmemfs領域にコピー
（やたらと時間がかかる。一瞬ハングしたかと思う）
[skobayas@localhost ~]$ ps alx|head -1 && ps alx| grep fuse
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 500 2261 1 20 0 35652 2180 futex_ Ssl ? 0:00 /usr/libexec//gvfs-fuse-daemon /home/skobayas/.gvfs
0 500 21935 2510 20 0 53088 8052 futex_ Sl+ pts/0 0:06 python example.py /tmp/fuse
0 500 21971 2584 20 0 5308 832 pipe_w S+ pts/1 0:00 grep fuse
RSSのフィールドに注目=>8052
8052-3824=4228
まぁ、妥当な増え方か？
4.続いて8M（1ケ）のファイルを同様にmemfs領域にコピー
（当然、4Mよりも時間がかかる）
[skobayas@localhost ~]$ ps alx|head -1 && ps alx| grep fuse
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 500 2261 1 20 0 35652 2180 futex_ Ssl ? 0:00 /usr/libexec//gvfs-fuse-daemon /home/skobayas/.gvfs
0 500 21935 2510 20 0 61092 16172 futex_ Sl+ pts/0 0:28 python example.py /tmp/fuse
0 500 21978 2584 20 0 5308 812 pipe_w S+ pts/1 0:00 grep fuse
RSSのフィールドに注目=>16172
16172-8052=8120
まぁ、妥当な増え方か?
5.最初に配置した4Mをコピーしてみる
[skobayas@localhost ~]$ cp /tmp/fuse/4m.bin /tmp/fuse/4m.bin.copy
[skobayas@localhost ~]$ ps alx|head -1 && ps alx| grep fuse
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 500 2261 1 20 0 35652 2180 futex_ Ssl ? 0:00 /usr/libexec//gvfs-fuse-daemon /home/skobayas/.gvfs
0 500 21935 2510 20 0 75872 20612 futex_ Sl+ pts/0 0:36 python example.py /tmp/fuse
0 500 21995 2584 20 0 5308 812 pipe_w S+ pts/1 0:00 grep fuse
引き続きRSSのフィールドに注目
20612-16172=4440
6.最初に配置した4Mを削除してみる
[skobayas@localhost ~]$ rm /tmp/fuse/4m.bin.copy
[skobayas@localhost ~]$ ps alx|head -1 && ps alx| grep fuse
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 500 2261 1 20 0 35652 2180 futex_ Ssl ? 0:00 /usr/libexec//gvfs-fuse-daemon /home/skobayas/.gvfs
0 500 21935 2510 20 0 75872 20612 futex_ Sl+ pts/0 0:36 python example.py /tmp/fuse
0 500 22000 2584 20 0 5308 808 pipe_w S+ pts/1 0:00 grep fuse
RSSのフィールドを確認するが、減ってない
example.pyの（デバッグ？）出力を見ているとunlinkしている。
ってことは実態はまだメモリ上にあるということか。
7.SymLinkしてみる
[skobayas@localhost ~]$ ln -s /tmp/fuse/4m.bin /tmp/fuse/4m.bin.lnk
[skobayas@localhost ~]$ ls -al /tmp/fuse/
合計 4
drwxr-xr-x 5 root root 0 2009-04-26 14:40 .
drwxrwxrwt 20 root root 4096 2009-04-26 14:40 ..
- rw-rw-r-- 1 root root 4096000 2009-04-26 14:42 4m.bin
lrwxrwxrwx 1 root root 16 1970-01-01 09:00 4m.bin.lnk -> /tmp/fuse/4m.bin
- rw-rw-r-- 1 root root 8192000 2009-04-26 14:47 8m.bin
日付がおかしいのはご愛嬌
（memoyfs.pyで改善されている？）
[skobayas@localhost ~]$ ps alx|head -1 && ps alx| grep fuse
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 500 2261 1 20 0 35652 2180 futex_ Ssl ? 0:00 /usr/libexec//gvfs-fuse-daemon /home/skobayas/.gvfs
0 500 21935 2510 20 0 75872 20620 futex_ Sl+ pts/0 0:36 python example.py /tmp/fuse
0 500 22029 2584 20 0 5308 812 pipe_w S+ pts/1 0:00 grep fuse
[skobayas@localhost ~]$
RSSフィールドは20620
20620-20612=8
i-node情報だけ増えるとしたらこんなもん？
ということで、
ディスクサイズは可変みたい（オンデマンドで大きくなる。小さくならない？）
メモリの確保はexample.pyが行っているということで一件落着
ただ、example.pyでもそこから呼ばれるfuse.pyでもmemoryfsとは指定してないように見えるのだけど。
なぞは続く
番外編：お約束のベンチマーク
[skobayas@localhost ~]$ dd if=/dev/zero of=/tmp/testimg bs=4k count=10
10+0 records in
10+0 records out
40960 bytes (41 kB) copied, 0.000852649 s, 48.0 MB/s
[skobayas@localhost ~]$ dd if=/dev/zero of=/tmp/fuse/testimg bs=4k count=10
10+0 records in
10+0 records out
40960 bytes (41 kB) copied, 0.585349 s, 70.0 kB/s
メモリなのにhddより遅いとは。
まぁ、FUSE自体、コンテクストスイッチが多発する設計なんだろうし、パフォーマンスよりも利便性ということなんだろうけど、
ちょっとなぁ。
と思ったら、デバッグ出力？がONになっていることを発見。
メイン呼び出しの
foreground=True
を
foreground=False
にしたところ、デバッグ出力はなくなるわ、即座にプロンプトが戻ってくるわ、普段使いはこっちか。
で、気になる結果は
[skobayas@localhost ~]$ dd if=/dev/zero of=/tmp/fuse/testimg bs=4k count=10
10+0 records in
10+0 records out
40960 bytes (41 kB) copied, 0.0299419 s, 1.4 MB/s
かなり?速くなった。
まぁ、それでもネイティブよりは遅いんだけど、裏で動いている手間を考えたら許容範囲か。
ちなみにもっと遅い?であろうloopbackではこんな感じ
[skobayas@localhost ~]$ dd if=/dev/zero of=/tmp/fuse/testimg bs=4k count=10
10+0 records in
10+0 records out
40960 bytes (41 kB) copied, 0.0351046 s, 1.2 MB/s
メモリに比べると若干遅いみたいだけど、意外なほど差は出ない感じ。
参考
===
[skobayas@localhost ~]$ df
Filesystem 1K-ブロック 使用 使用可 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
6966792 2493788 4402312 37% /
/dev/sda1 194442 20859 163544 12% /boot
tmpfs 256976 76 256900 1% /dev/shm
Loopback 6966792 2493788 4402312 37% /tmp/fuse
===
090428
エントリカテゴリの整理
Subjectの変更
