かなり昔に書いた資料(2009)ですが、上げ直します。
情報漏洩の側面から見ると、ハードディスクの中身は基本的には「消したい」わけだが、
運用中では、人間が間違って削除する場合も多々あり、データを復活させたい場合の方が多い。
以前では「バックアップ」しか手が無かったが、ハードディスクの大容量化と、
オープンソースの流行と相まって、ファイルシステムレベルでのサポートが増えてきた。
●nilfs2 ( 2.0.12 ) http://www.nilfs.org/ja/
linux専用。
5秒単位で「チェックポイント」を自動的に作る。「チェックポイント」は一定時間で削除する(その為のユーザランドツールがある)が、「チェックポイント」を「スナップショット」に転換してそれをマウントすることが出来る。
コンセプト的には、個人的理想に近い。しかし、大きなファイル(数百Mb〜数Gb)を読み書き&削除するようには出来てなさそうに見える。大きなファイルのリネーム等をすると、数秒ラグがある。「あ、コピーしてるな」感。USBストレージではバス速度が足りない模様。
少ないメモリでも稼働するが、メモリ確保失敗で、カーネルモジュールが死ぬ場合がある。
その場合でも、再起動してマウントすれば、ファイルはまったくの無事ではある。
細かいファイルを大量に運用するような場合には、問題は出にくいと思う。
ホームディレクトリのパーティションに向いているかと思う。
パーティションのuuidが付かないので、/dev/disk/by-id/ 等でマウントする必要がある。
●unionfs, aufs http://unionfs.filesystems.org/ http://aufs.sourceforge.net/
バックエンドに、通常のファイルシステムを置いて、fuse経由でその書き込みを交通整理する。
元々はlivecd-linux用の技術だが、もちろんハードディスクのディレクトリ同士を重ねることは出来る。
複数のファイルシステムを「重ねる」場合、一つを除いてすべてreadonly。全ての書き込みは単一のファイルシステムにまとまる。ファイルの削除等でも、特殊な制御ファイルで、「再現」している。
「復活」に使うのであれば、書き込みファイルシステムから、readonlyファイルシステムに移動 OR コピーすれば良い。しかしこれは完全に裏技。unionfs経由からファイルが見えなくなることがある。
最も成功している運用例は、ASUS eeePC の xandrosだろう。「工場出荷状態」をroパーティションに保持して、ユーザデータをrwパーティションに書く。つまりコンセプト通りに、「絶対書き換えないモノ」＋「を、書き換える様に見せる」で使うべき。
●zfs-fuse ( 0.5 )http://zfs-fuse.net/ → 2013年現在は native zfs on linuxが継承
SunのSolarisが出生のファイルシステム。それにより、CDDLという特殊なライセンスで、GPLとは相容れないらしい。それ故、2009年現在 linux での運用はやや難あり。後述。
ストレージボリュームを統合し再構築する。linux volume managementに近いが、完成度はzfsの方が高いように思う。snapshotだけではなく、それを使ったrollbackもサポートする。
zfsを使うには色々選択肢があるわけだが、OpenSolarisはS-ATAをサポートしてない模様なので、FreeBSD 7か、linuxのzfs-fuseしか選択肢は残らない。※2009年現在
linux使いとしては、手軽に使えるのはzfs-fuseなのだが、fuseである為にnfsがサポート出来ない。ファイルサーバに仕込むつもりだったので、色々トホホな感あり。sambaでも良いのだが、個人的にはファイル名に半角不等号を使いたい事情があり、結構問題あり。
zfs-fuse 0.4は性能に問題がある気がしてたが、USBハブのトラフィックのせいかもしれない。
zfs-fuse 0.5は、USBドライブ同士のコピーで、11MB/s程度は出ている。(理論値の半分弱)
本家OpenSolarisは、メモリ768MB未満では、インストーラが起動しないらしい。本来の推奨環境はメモリ8GB以上。ゲームPCかグラフィック商売でしか聞いたことがない容量。メモリを馬鹿食いするようだ。
zfs-fuseは、実256Mbでも動作はする。ただしCPUパワーもメモリも使う。
Sun自身がヘビーユーザなのだろう。運用体系は良く練り込まれている。
zpoolがハードディスク管理、zfsが領域管理、と区別しているようだ。
zpoolは滅多に使わないので、パーミッションを落とすぐらいで良いかもしれない。
#zfs-fuseはbootで使っている模様。他は知らない。
zpool createで直ぐにマウントする。mkfs.zfsが有るもんだと思ってたので、軽く衝撃。しかも、パーティション(の様なもの)は後から切れる。切っただけで、容積はその時点では割り振ってない。制限をかけることはもちろん可能。これのお陰で、例えばユーザ単位でパーティションを切っても良いだろう。確かにこれが出来るのなら、慌ててパーティションを切らせたり、フォーマットさせたりする必要は無いだろう。
逆に、ユーザ単位でのquotaは実装してないようだ。パーティションの細分化で代替するコンセプトなのだろうと思う。
大きなファイルを大量に扱っても、特に性能が落ちる感はない。zpool destoryでパーティションが消えてなくなるが、直後であれば zpool import -Dで復活する。
#私はアッサリ諦めてzpool createしなおしてしまった。もちろんもう復活は無理。
zfs-fuseでは、再起動で、zfsパーティションを勝手にマウントする。本家(OpenSolaris)やFreeBSDでもそうなのかどうかは知らない。USBドライブだとデバイス名が変わりそうな予感がしたので、disk/by-idを使ったが、実際には、再起動時には該当デバイスを勝手に探すらしい。パーティション情報のimport/exportを実装したのなら、これは可能だろう。よく練り込まれている。
総評としては「ファイルサーバ」向き。
linuxではnfsが使えないのでメリットは半減する。ストレージバスは、内蔵 or S-ATA 向きかもしれない。少なくともドライブを頻繁に着脱するようなコンセプトではない。
一晩掛かって、IEEE1394aの外付けドライブに移行した。CPU使用率は相変わらずだが、レスポンスは劇的に改善した。USBバスネックであったようだ。
情報漏洩の側面から見ると、ハードディスクの中身は基本的には「消したい」わけだが、
運用中では、人間が間違って削除する場合も多々あり、データを復活させたい場合の方が多い。
以前では「バックアップ」しか手が無かったが、ハードディスクの大容量化と、
オープンソースの流行と相まって、ファイルシステムレベルでのサポートが増えてきた。
●nilfs2 ( 2.0.12 ) http://www.nilfs.org/ja/
linux専用。
5秒単位で「チェックポイント」を自動的に作る。「チェックポイント」は一定時間で削除する(その為のユーザランドツールがある)が、「チェックポイント」を「スナップショット」に転換してそれをマウントすることが出来る。
コンセプト的には、個人的理想に近い。しかし、大きなファイル(数百Mb〜数Gb)を読み書き&削除するようには出来てなさそうに見える。大きなファイルのリネーム等をすると、数秒ラグがある。「あ、コピーしてるな」感。USBストレージではバス速度が足りない模様。
少ないメモリでも稼働するが、メモリ確保失敗で、カーネルモジュールが死ぬ場合がある。
その場合でも、再起動してマウントすれば、ファイルはまったくの無事ではある。
細かいファイルを大量に運用するような場合には、問題は出にくいと思う。
ホームディレクトリのパーティションに向いているかと思う。
パーティションのuuidが付かないので、/dev/disk/by-id/ 等でマウントする必要がある。
●unionfs, aufs http://unionfs.filesystems.org/ http://aufs.sourceforge.net/
バックエンドに、通常のファイルシステムを置いて、fuse経由でその書き込みを交通整理する。
元々はlivecd-linux用の技術だが、もちろんハードディスクのディレクトリ同士を重ねることは出来る。
複数のファイルシステムを「重ねる」場合、一つを除いてすべてreadonly。全ての書き込みは単一のファイルシステムにまとまる。ファイルの削除等でも、特殊な制御ファイルで、「再現」している。
「復活」に使うのであれば、書き込みファイルシステムから、readonlyファイルシステムに移動 OR コピーすれば良い。しかしこれは完全に裏技。unionfs経由からファイルが見えなくなることがある。
最も成功している運用例は、ASUS eeePC の xandrosだろう。「工場出荷状態」をroパーティションに保持して、ユーザデータをrwパーティションに書く。つまりコンセプト通りに、「絶対書き換えないモノ」＋「を、書き換える様に見せる」で使うべき。
●zfs-fuse ( 0.5 )
SunのSolarisが出生のファイルシステム。それにより、CDDLという特殊なライセンスで、GPLとは相容れないらしい。それ故、2009年現在 linux での運用はやや難あり。後述。
ストレージボリュームを統合し再構築する。linux volume managementに近いが、完成度はzfsの方が高いように思う。snapshotだけではなく、それを使ったrollbackもサポートする。
zfsを使うには色々選択肢があるわけだが、OpenSolarisはS-ATAをサポートしてない模様なので、FreeBSD 7か、linuxのzfs-fuseしか選択肢は残らない。※2009年現在
linux使いとしては、手軽に使えるのはzfs-fuseなのだが、fuseである為にnfsがサポート出来ない。ファイルサーバに仕込むつもりだったので、色々トホホな感あり。sambaでも良いのだが、個人的にはファイル名に半角不等号を使いたい事情があり、結構問題あり。
zfs-fuse 0.4は性能に問題がある気がしてたが、USBハブのトラフィックのせいかもしれない。
zfs-fuse 0.5は、USBドライブ同士のコピーで、11MB/s程度は出ている。(理論値の半分弱)
本家OpenSolarisは、メモリ768MB未満では、インストーラが起動しないらしい。本来の推奨環境はメモリ8GB以上。ゲームPCかグラフィック商売でしか聞いたことがない容量。メモリを馬鹿食いするようだ。
zfs-fuseは、実256Mbでも動作はする。ただしCPUパワーもメモリも使う。
Sun自身がヘビーユーザなのだろう。運用体系は良く練り込まれている。
zpoolがハードディスク管理、zfsが領域管理、と区別しているようだ。
zpoolは滅多に使わないので、パーミッションを落とすぐらいで良いかもしれない。
#zfs-fuseはbootで使っている模様。他は知らない。
zpool createで直ぐにマウントする。mkfs.zfsが有るもんだと思ってたので、軽く衝撃。しかも、パーティション(の様なもの)は後から切れる。切っただけで、容積はその時点では割り振ってない。制限をかけることはもちろん可能。これのお陰で、例えばユーザ単位でパーティションを切っても良いだろう。確かにこれが出来るのなら、慌ててパーティションを切らせたり、フォーマットさせたりする必要は無いだろう。
逆に、ユーザ単位でのquotaは実装してないようだ。パーティションの細分化で代替するコンセプトなのだろうと思う。
大きなファイルを大量に扱っても、特に性能が落ちる感はない。zpool destoryでパーティションが消えてなくなるが、直後であれば zpool import -Dで復活する。
#私はアッサリ諦めてzpool createしなおしてしまった。もちろんもう復活は無理。
zfs-fuseでは、再起動で、zfsパーティションを勝手にマウントする。本家(OpenSolaris)やFreeBSDでもそうなのかどうかは知らない。USBドライブだとデバイス名が変わりそうな予感がしたので、disk/by-idを使ったが、実際には、再起動時には該当デバイスを勝手に探すらしい。パーティション情報のimport/exportを実装したのなら、これは可能だろう。よく練り込まれている。
総評としては「ファイルサーバ」向き。
linuxではnfsが使えないのでメリットは半減する。ストレージバスは、内蔵 or S-ATA 向きかもしれない。少なくともドライブを頻繁に着脱するようなコンセプトではない。
一晩掛かって、IEEE1394aの外付けドライブに移行した。CPU使用率は相変わらずだが、レスポンスは劇的に改善した。USBバスネックであったようだ。
