アカウント名:
パスワード:
ちょっとした疑問です、ZFS の新機能は Solaris に実装される方が早いのではないかと思うのですが(本家ですし)あえて FreeBSD の ZFS なのにはこだわりがあるのでしょうか？
余ったパーツ(むしろ余らせた) + 奮発した HDD でFreeBSD で ZFS な NAS を作ってみたいなぁと思っているので気になるところです。
ちなみに今は動画の類を NTFS な HDD に放り込んでいます。HDD をつないで再生できるメディアプレーヤなどでも NTFS 対応は結構あるようなので。PS3 は FAT32 だけですけど DLNA で再生するから問題なし。
# 自分が FreeBSD なのは単純に Ubuntu と FreeBSD 位しか触ったことがないから……
ZFS の新機能は Solaris に実装される方が早いのではないかと思うのですが(本家ですし)あえて FreeBSD の ZFS なのにはこだわりがあるのでしょうか？
素晴らしい質問です。「なぜ一番最初にリリースされるものを使わないのか」
.
理由は「バグを回避するため」。
ZFSに限りませんが、この手のプログラム、バグは2種類あります。
1) 機能を定義し、最初の実装を行った段階で入り込んだバグ。経験不足(そりゃ、初めてですから)に起因する 考慮不足などのせいで、うまく行くと思っていたことがうまくいかなくてギャーー 的な問題2) 1を一通りクリア
>理由は「バグを回避するため」。...>なので、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は安定していますので説得力がありません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
どういうアクセス方式でつかうのか問わないなら… (スコア:5, 参考になる)
Windows とかだと raw device へのアクセス方法を手に入れるのが最大の問題になるだろう。が、一旦そこをどうにかすれば、tar のソースコードは世の中に出回っているからどうにかこうにかなるだろう。
最大の問題点は32bitにしか対応していない tar を使ってしまった場合かな。今つかうなら、最低限でも64bit対応でないと困るだろう。できれば 1024bit に拡張してから…
fjの教祖様
Re: (スコア:1)
ちょっとした疑問です、
ZFS の新機能は Solaris に実装される方が早いのではないかと思うのですが(本家ですし)
あえて FreeBSD の ZFS なのにはこだわりがあるのでしょうか？
余ったパーツ(むしろ余らせた) + 奮発した HDD で
FreeBSD で ZFS な NAS を作ってみたいなぁと思っているので気になるところです。
ちなみに今は動画の類を NTFS な HDD に放り込んでいます。
HDD をつないで再生できるメディアプレーヤなどでも NTFS 対応は結構あるようなので。
PS3 は FAT32 だけですけど DLNA で再生するから問題なし。
# 自分が FreeBSD なのは単純に Ubuntu と FreeBSD 位しか触ったことがないから……
Re: (スコア:5, 参考になる)
素晴らしい質問です。「なぜ一番最初にリリースされるものを使わないのか」
.
理由は「バグを回避するため」。
ZFSに限りませんが、この手のプログラム、バグは2種類あります。
1) 機能を定義し、最初の実装を行った段階で入り込んだバグ。経験不足(そりゃ、初めてですから)に起因する
考慮不足などのせいで、うまく行くと思っていたことがうまくいかなくてギャーー 的な問題
2) 1を一通りクリア
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)