「FreeBSD 6.0 リリース」記事へのコメント

Bittorrentでの公式配布開始

[KENN (3839)]

リリースアナウンスに

The FreeBSD project encourages the use of BitTorrent for distributing the release ISO images.

とあるように、FreeBSD ProjectとしてBittorrentでのISOイメージ配布を推奨してます。これに伴い、trackerも公式ftpサイトのmirrorの対象になっている [freebsd.org]ようです。

Bittorrentによる配布自体は前からやってますが、5.4-RELEASEの時は"experimenting" [freebsd.org]でした。

RingServerではミラー終了

[k_f (18123)]

一方で、RingServer ProjectではFreeBSD（本家、jp、PC98）のミラーを12月1日で終了 [ring.gr.jp]するようですね。

ボリュームが相当のサイズになってディスク領域を圧迫いるのと、一方でRingServer以外の国内ミラーが十分整備されているということで、まあ何とかなるだろうという判断のようです。妥当な判断だと思いますが、さてBitTorrentが認められていない我が組織の環境ではどんな影響があるか……

Re:RingServerではミラー終了

[Anonymous Coward]

実際に容量を食っているのはどこなんだ、という話:
(http://pc8.2ch.net/test/read.cgi/unix/1128614150/404 を丸々転載)

> 手近のringサーバを見たらdir.sizesというファイルがあったので覗いてみたわよ。
> 適当に抽出するとこんな感じ(桁合わせには自身がないのでずれてたらnavi2chでみてね)
> 14856138 ./ports/alpha
> 39554526 ./ports/amd64
> 25438914 ./ports/distfiles
> 10985352 ./ports/i386/packages-6-current
> 11834310 ./ports/i386/packages-4-stable
> 11988144 ./ports/i386/packages-5-stable
> 12046396 ./ports/i386/packages-4.11-release
> 11317404 ./ports/i386/packages-7-current
> 10889868 ./ports/i386/packages-5.4-release
> 10682292 ./ports/i386/packages-6.0-release
> 12 ./ports/i386/tmp
> 79743782 ./ports/i386
> 22802712 ./ports/ia64
> 1720680 ./ports/local-distfiles
> 32939600 ./ports/sparc64
> 217084982 ./ports
> 35479626 ./releases
> 270877118 .
> これを見ると、distfilesの共通化はやったとしても効果は限定的で、
> パッケージの占める容量が支配的であることがわかる。
> FreeBSDでバージョン5,6のもたつきから4本のメジャーな枝が併存しているとい
> う状態が今回の決定の一因になったのではなかろうか。
> なにもフルミラーが難しいからといってバッサリ捨て去ることはないと思うが
> 部分的ミラーは人手の調整が発生するので難しい面もあるのだろう。
> distfilesだけを/pub/FreeBSD-distfiles とでもして残すというのはFreeBSD
> 以外のOSでも有益だしRing側の手間もかからないので一つの妥協点だと思う。
> オリジナルの配布物そのままの集積点としては最大だろうし。

Re:RingServerではミラー終了

[Anonymous Coward]

ミラーサイトなんて、何台あっても所詮ヘッドナンバー(もしくはノーナンバー)しか使われないんですよ。

「ミラーサイトが遅い」ってわめく奴に限ってそうだから...

Re:RingServerではミラー終了

[ginga (20279)]

ノーナンバー・先頭番号は DNS round-robin にしてしまえ，っていうのはダメですかね?

Re:RingServerではミラー終了

[Anonymous Coward]

ftp.freebsd.orgがRRなのだが、passive modeの違いでそれぞれ挙動が異なってる。
多分RRは不幸になるだけだろ。

ミラーのタイミング次第じゃ

・片方にミラー完了して、片方はまだミラーしてない。
・片方からは削除されたが、片方はまだ削除してない。

なんてのがゴロゴロ出てきそう。特に、こういうリリース直後だと、
顕著化して余計な混乱招くだけだろう。

RRが有用なのは「同一の管理者が手を掛けてメンテナンス」
してる時だけ。

Re:RingServerではミラー終了

[Anonymous Coward]

こういうのってFreeBSDのミラーのような大きな話でなくても結構ありますよね。誰か commit/rollback をサポートしたファイルシステムとか作らないかな（他力本願）。

単にアトミックに入れ替えるだけなら簡単だけど、差分転送しながらアトミックに入れ替えるのはどうしたらいいのだろう。
ファイルシステムのスナップショットを取ってそちらを公開用に一時的に切り替えて、同期を取ったら本来のファイルシステムのほうに張り替えればいけるのかな？

Re:RingServerではミラー終了

[Ying (4319)]

単純なDNSラウンドロビンの類だと、ミラーのいきわたるタイミングの問題で、飛ばされたサーバにファイルが存在しなかったという状況が発生するのが問題ですね。特にアクセスの最も集中するリリース直後に。

何度かそういう状況に遭遇すると、意識してラウンドロビンされたURL*だけ*を避けるようになります。