アカウント名:
パスワード:
「外に出せるものは外に出してしまい、まずバックアップしなくちゃいけないデータ量を減らせ」「Network File System (NFS じゃなくても AFS でも CoDa でも何でもいいが)で共有する事で、そもそもコピーを減らせ」「バックアップは複数取っておけ。できれば違うフォーマットで」という鉄則がまずあるかとは思いますが、それらを配慮した上でならばこんな感じじゃないかと。
ちょっとした疑問です、ZFS の新機能は Solaris に実装される方が早いのではないかと思うのですが(本家ですし)あえて FreeBSD の ZFS なのにはこだわりがあるのでしょうか？
余ったパーツ(むしろ余らせた) + 奮発した HDD でFreeBSD で ZFS な NAS を作ってみたいなぁと思っているので気になるところです。
ちなみに今は動画の類を NTFS な HDD に放り込んでいます。HDD をつないで再生できるメディアプレーヤなどでも NTFS 対応は結構あるようなので。PS3 は FAT32 だけですけど DLNA で再生するから問題なし。
# 自分が FreeBSD なのは単純に Ubuntu と FreeBSD 位しか触ったことがないから……
余ったパーツでzfsを使用したFreeBSDサーバを構築する場合, 次の2点には注意しておいた方が良いです.
32bit対応のみのCPUでも使えないことは無いのですが, amd64版だとチューニングパラメータをいちいちいじらなくてもよろしくやってくれるので, かなり楽ができます. またzfsを使用するとカーネルがキャッシュやらなんやらで512MB以上消費する場合があるので, メモリ1GBぐらいが最低限のラインになります.(カーネルに割り当てたメモリが足らなくなるとpanicで落ちます)
このあたりは細かくパラメータを調整したり, あるいは最近のzfs v13では改善されているかもしれませんが, 安全パイを取るならamd64で4GB以上(最近ではそれほどきつい条件ではなくなりましたから)ってのが目安でしょう. そういう意味ではzfsに限ればSolarisの方が安全・確実と言えるかもしれません.
ZFS の新機能は Solaris に実装される方が早いのではないかと思うのですが(本家ですし)あえて FreeBSD の ZFS なのにはこだわりがあるのでしょうか？
素晴らしい質問です。「なぜ一番最初にリリースされるものを使わないのか」
.
理由は「バグを回避するため」。
ZFSに限りませんが、この手のプログラム、バグは2種類あります。
1) 機能を定義し、最初の実装を行った段階で入り込んだバグ。経験不足(そりゃ、初めてですから)に起因する 考慮不足などのせいで、うまく行くと思っていたことがうまくいかなくてギャーー 的な問題2) 1を一通りクリアした後、2つ目のOSに移植する際に、ベースのOSの性質が違ったり、 インターフェースを合わせるために無理をしたときに出てくるバグ。
2 の場合、ストレージレベルでのフォーマット間違いとか、そう言うのは余り出てきません。マウントできないとか、バイナリレベルで読んでみたら Solaris 版と出て着るものがぜんぜん違うわこれ、とか、結構初期の段階で発見、fix できる。本質的にうまく行くのは 1 を通過した後なので大丈夫。
なので、Solaris ZFSではなく、FreeBSD ZFS であればかなり信頼できるものが最初から出てくるに違いない、とそういうわけです。
この手の情報は、man page を良く読んでいると判ることがあります。某OSに ext2 が移植された際、bugs の項にはこう書かれていました。「オリジナルと異なり、同期書き込みでは、ちゃんと同期的に書き込んでしまう。」
このように、オリジナル側が「無い」と主張しているバグについて、コメントが皮肉っぽく書かれたらもう大丈夫。
>理由は「バグを回避するため」。...>なので、Solaris ZFSではなく、FreeBSD ZFS であればかなり信頼できるものが最初から出てくるに違いない、とそういうわけです。
portingのバグは考えないの? 現にFreeBSDでzfsが導入されてからずっと、結構不安定な状態が続いていたよね。新しいバージョンの最初を避けるというのであれば、zfsはSXCE→OpenSolaris→Solaris10の順番で流れてくるから、Solaris10を使うってのが安心だと思うけど。
portingのバグは考えないの?
porting のバグは 2 の一部として考慮してありますが。重複除去は、基本的にファイルシステムの上で動作するものです。なので 1 と 2 では、 1 の比重が圧倒的に高い。
現にFreeBSDでzfsが導入されてからずっと、結構不安定な状態が続いていたよね。
続いてますね。だからこそ FreeBSD にポートされるのを待つべきなんです。
すでに述べたようにバグには2種類あります。1つ目はそもそもの実装案に内在する「思慮不足」起因のバグ。
2つ目は「純粋に実装起因の」バグ。porting などで特に露呈しますが、ようするに外部とのインターフェース、外部へのインターフェースの不整合に起因するバグです。
「ZFS を実装/移植する」事そのものは、実は 1 のバグと 2 のバグが同じぐらい存在します。というか、同じ程度にしか存在しません。ファイルシステムそのものは世の中に沢山存在します。実装はいくつもオープンになっており、論文も沢山出ている。このため、1 の部分で失敗する事は少ない。 2 の部分で「あ…特定のOSへの実装に偏りすぎた」と言うのが露呈する事が多い。
それが FreeBSD に移植する際に起こっている事です。もっと言えば、FreeBSD に移植する際に発見された問題のいくつかは、本家本元がインターフェースに対して立てていた大前提が間違っていたと言うことで、他のOSでも同様の問題となって発現するでしょう。異なるOSのメンテナは異なる視点からプログラムの動作をチェックするので、「安定しない」のは当たり前です。
しかし「ZFS に重複除去機能を追加する」場合は、1 のバグが殆どで、2のバグは殆ど出てこないはずです。重複除去機能そのものが可能なのは、すでに商用システムにそのようなものが存在することから自明です。しかし、これを実装した際にどのような問題が起こり得るのかは、従来のファイルシステム実装自身程判っているわけじゃない。つまり 1 が発生する確率は、ファイルシステムそのものを実装する際よりも、高い。
これに対して、2、つまり重複除去機能が完成した場合にこれを「FreeBSD 上で動作している ZFS に追加する」場合に生じる porting bug は圧倒的に少なくなる。なぜなら、重複除去機能は ZFS の「内部機能」だから。重複除去のために追加されなくてはいけない OS 外部とのインターフェースは遥かに少なくて済むはずです。と言うことは 2 にともなうバグは圧倒的に少なくて済む。
しかるに。1のバグがまだ不安な状態で別のOSのメンテナが port を始めることはありません。無駄足に終わる可能性が非常に高いからです。
この二つを混同して評価するのは、プログラミングにおいてバグがどういう具合に発生するのか、その本質を理解していない証拠と言えます。
>> 現にFreeBSDでzfsが導入されてからずっと、結構不安定な状態が続いていたよね。>続いてますね。だからこそ FreeBSD にポートされるのを待つべきなんです。
それはFreeBSDと同様の障害がSolaris 10『でも』出ている場合には言えるかも知れません。しかし、ぶっちゃけSolaris 10のzfsは安定していますので説得力がありません。
ここ [linux.or.jp]で指摘されているとおりtarは一部が破壊されるとそれより後ろに書き込まれたファイルを読み出すことが困難になるので、直接ストレージに書き込むにしてもフォーマットはafioやISO9660にしておく方がオススメです。
そのようですね書いてから気づきました
# afioとか言い出したAC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
どういうアクセス方式でつかうのか問わないなら… (スコア:5, 参考になる)
Windows とかだと raw device へのアクセス方法を手に入れるのが最大の問題になるだろう。が、一旦そこをどうにかすれば、tar のソースコードは世の中に出回っているからどうにかこうにかなるだろう。
最大の問題点は32bitにしか対応していない tar を使ってしまった場合かな。今つかうなら、最低限でも64bit対応でないと困るだろう。できれば 1024bit に拡張してから…
バックアップの場合、普段使いと違ってフラグメンテーションを起こしまくったファイルシステムでも大きな問題はない。むしろ大事なのは同じデータ部分を持ったファイルが幾つもあったりした場合に、こいつのせいでメディアがどんどん肥大化するのをどうやって止めるか。
そこで重複除去機能。ZFSにこいつが入るのを待って、Raid1-6構成のメディア上にZFSを構築してそこにデータを保存しろ。そうすれば重複情報は削除しつつ、信頼性を確保出来る。
「外に出せるものは外に出してしまい、まずバックアップしなくちゃいけないデータ量を減らせ」
「Network File System (NFS じゃなくても AFS でも CoDa でも何でもいいが)で共有する事で、そもそもコピーを減らせ」
「バックアップは複数取っておけ。できれば違うフォーマットで」
という鉄則がまずあるかとは思いますが、それらを配慮した上でならばこんな感じじゃないかと。
fjの教祖様
Re:どういうアクセス方式でつかうのか問わないなら… (スコア:1)
ちょっとした疑問です、
ZFS の新機能は Solaris に実装される方が早いのではないかと思うのですが(本家ですし)
あえて FreeBSD の ZFS なのにはこだわりがあるのでしょうか？
余ったパーツ(むしろ余らせた) + 奮発した HDD で
FreeBSD で ZFS な NAS を作ってみたいなぁと思っているので気になるところです。
ちなみに今は動画の類を NTFS な HDD に放り込んでいます。
HDD をつないで再生できるメディアプレーヤなどでも NTFS 対応は結構あるようなので。
PS3 は FAT32 だけですけど DLNA で再生するから問題なし。
# 自分が FreeBSD なのは単純に Ubuntu と FreeBSD 位しか触ったことがないから……
Re:どういうアクセス方式でつかうのか問わないなら… (スコア:5, 参考になる)
余ったパーツでzfsを使用したFreeBSDサーバを構築する場合, 次の2点には注意しておいた方が良いです.
32bit対応のみのCPUでも使えないことは無いのですが, amd64版だとチューニングパラメータをいちいちいじらなくてもよろしくやってくれるので, かなり楽ができます. またzfsを使用するとカーネルがキャッシュやらなんやらで512MB以上消費する場合があるので, メモリ1GBぐらいが最低限のラインになります.(カーネルに割り当てたメモリが足らなくなるとpanicで落ちます)
このあたりは細かくパラメータを調整したり, あるいは最近のzfs v13では改善されているかもしれませんが, 安全パイを取るならamd64で4GB以上(最近ではそれほどきつい条件ではなくなりましたから)ってのが目安でしょう. そういう意味ではzfsに限ればSolarisの方が安全・確実と言えるかもしれません.
Re:どういうアクセス方式でつかうのか問わないなら… (スコア:5, 参考になる)
素晴らしい質問です。「なぜ一番最初にリリースされるものを使わないのか」
.
理由は「バグを回避するため」。
ZFSに限りませんが、この手のプログラム、バグは2種類あります。
1) 機能を定義し、最初の実装を行った段階で入り込んだバグ。経験不足(そりゃ、初めてですから)に起因する
考慮不足などのせいで、うまく行くと思っていたことがうまくいかなくてギャーー 的な問題
2) 1を一通りクリアした後、2つ目のOSに移植する際に、ベースのOSの性質が違ったり、
インターフェースを合わせるために無理をしたときに出てくるバグ。
2 の場合、ストレージレベルでのフォーマット間違いとか、そう言うのは余り出てきません。マウントできないとか、バイナリレベルで読んでみたら Solaris 版と出て着るものがぜんぜん違うわこれ、とか、結構初期の段階で発見、fix できる。本質的にうまく行くのは 1 を通過した後なので大丈夫。
なので、Solaris ZFSではなく、FreeBSD ZFS であればかなり信頼できるものが最初から出てくるに違いない、とそういうわけです。
.
この手の情報は、man page を良く読んでいると判ることがあります。
某OSに ext2 が移植された際、bugs の項にはこう書かれていました。
「オリジナルと異なり、同期書き込みでは、ちゃんと同期的に書き込んでしまう。」
このように、オリジナル側が「無い」と主張しているバグについて、コメントが皮肉っぽく書かれたらもう大丈夫。
fjの教祖様
Re:どういうアクセス方式でつかうのか問わないなら… (スコア:1, 興味深い)
>理由は「バグを回避するため」。
...
>なので、Solaris ZFSではなく、FreeBSD ZFS であればかなり信頼できるものが最初から出てくるに違いない、とそういうわけです。
portingのバグは考えないの? 現にFreeBSDでzfsが導入されてからずっと、結構不安定な状態が続いていたよね。
新しいバージョンの最初を避けるというのであれば、zfsはSXCE→OpenSolaris→Solaris10の順番で流れてくるから、Solaris10を使うってのが安心だと思うけど。
Re:どういうアクセス方式でつかうのか問わないなら… (スコア:2, 興味深い)
porting のバグは 2 の一部として考慮してありますが。
重複除去は、基本的にファイルシステムの上で動作するものです。なので 1 と 2 では、 1 の比重が圧倒的に高い。
続いてますね。だからこそ FreeBSD にポートされるのを待つべきなんです。
.
すでに述べたようにバグには2種類あります。
1つ目はそもそもの実装案に内在する「思慮不足」起因のバグ。
2つ目は「純粋に実装起因の」バグ。porting などで特に露呈しますが、ようするに外部とのインターフェース、外部へのインターフェースの不整合に起因するバグです。
「ZFS を実装/移植する」事そのものは、実は 1 のバグと 2 のバグが同じぐらい存在します。というか、同じ程度にしか存在しません。ファイルシステムそのものは世の中に沢山存在します。実装はいくつもオープンになっており、論文も沢山出ている。このため、1 の部分で失敗する事は少ない。 2 の部分で「あ…特定のOSへの実装に偏りすぎた」と言うのが露呈する事が多い。
それが FreeBSD に移植する際に起こっている事です。もっと言えば、FreeBSD に移植する際に発見された問題のいくつかは、本家本元がインターフェースに対して立てていた大前提が間違っていたと言うことで、他のOSでも同様の問題となって発現するでしょう。異なるOSのメンテナは異なる視点からプログラムの動作をチェックするので、「安定しない」のは当たり前です。
.
しかし「ZFS に重複除去機能を追加する」場合は、1 のバグが殆どで、2のバグは殆ど出てこないはずです。重複除去機能そのものが可能なのは、すでに商用システムにそのようなものが存在することから自明です。しかし、これを実装した際にどのような問題が起こり得るのかは、従来のファイルシステム実装自身程判っているわけじゃない。つまり 1 が発生する確率は、ファイルシステムそのものを実装する際よりも、高い。
これに対して、2、つまり重複除去機能が完成した場合にこれを「FreeBSD 上で動作している ZFS に追加する」場合に生じる porting bug は圧倒的に少なくなる。なぜなら、重複除去機能は ZFS の「内部機能」だから。重複除去のために追加されなくてはいけない OS 外部とのインターフェースは遥かに少なくて済むはずです。と言うことは 2 にともなうバグは圧倒的に少なくて済む。
しかるに。1のバグがまだ不安な状態で別のOSのメンテナが port を始めることはありません。無駄足に終わる可能性が非常に高いからです。
.
この二つを混同して評価するのは、プログラミングにおいてバグがどういう具合に発生するのか、その本質を理解していない証拠と言えます。
fjの教祖様
Re: (スコア:0)
>> 現にFreeBSDでzfsが導入されてからずっと、結構不安定な状態が続いていたよね。
>続いてますね。だからこそ FreeBSD にポートされるのを待つべきなんです。
それはFreeBSDと同様の障害がSolaris 10『でも』出ている場合には言えるかも知れません。
しかし、ぶっちゃけSolaris 10のzfsは安定していますので説得力がありません。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
ここ [linux.or.jp]で指摘されているとおりtarは一部が破壊されるとそれより後ろに書き込まれたファイルを読み出すことが困難になるので、直接ストレージに書き込むにしてもフォーマットはafioやISO9660にしておく方がオススメです。
Re:どういうアクセス方式でつかうのか問わないなら… (スコア:1)
Re: (スコア:0)
そのようですね
書いてから気づきました
# afioとか言い出したAC