パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

  • リリースアナウンスに

    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]でした。

    • by k_f (18123) on 2005年11月05日 10時54分 (#826242)
      一方で、RingServer ProjectではFreeBSD(本家、jp、PC98)のミラーを12月1日で終了 [ring.gr.jp]するようですね。

      ボリュームが相当のサイズになってディスク領域を圧迫いるのと、一方でRingServer以外の国内ミラーが十分整備されているということで、まあ何とかなるだろうという判断のようです。妥当な判断だと思いますが、さてBitTorrentが認められていない我が組織の環境ではどんな影響があるか……
      親コメント
      • by Anonymous Coward on 2005年11月05日 14時41分 (#826365)
        実際に容量を食っているのはどこなんだ、という話:
        (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側の手間もかからないので一つの妥協点だと思う。
        > オリジナルの配布物そのままの集積点としては最大だろうし。

        親コメント
      • by Anonymous Coward on 2005年11月05日 11時22分 (#826252)
        ミラーサイトなんて、何台あっても所詮ヘッドナンバー(もしくはノーナンバー)しか使われないんですよ。

        「ミラーサイトが遅い」ってわめく奴に限ってそうだから...
        親コメント
        • by ginga (20279) on 2005年11月05日 14時43分 (#826368)
          ノーナンバー・先頭番号は DNS round-robin にしてしまえ,っていうのはダメですかね?
          親コメント
          • by Anonymous Coward on 2005年11月05日 17時19分 (#826466)
            ftp.freebsd.orgがRRなのだが、passive modeの違いでそれぞれ挙動が異なってる。
            多分RRは不幸になるだけだろ。

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

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

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

            RRが有用なのは「同一の管理者が手を掛けてメンテナンス」
            してる時だけ。
            親コメント
            • こういうのってFreeBSDのミラーのような大きな話でなくても結構ありますよね。誰か commit/rollback をサポートしたファイルシステムとか作らないかな(他力本願)。

              単にアトミックに入れ替えるだけなら簡単だけど、差分転送しながらアトミックに入れ替えるのはどうしたらいいのだろう。
              ファイルシステムのスナップショットを取ってそちらを公開用に一時的に切り替えて、同期を取ったら本来のファイルシステムのほうに張り替えればいけるのかな?
          • by Ying (4319) on 2005年11月05日 17時20分 (#826469)
            単純なDNSラウンドロビンの類だと、ミラーのいきわたるタイミングの問題で、飛ばされたサーバにファイルが存在しなかったという状況が発生するのが問題ですね。特にアクセスの最も集中するリリース直後に。

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

            親コメント

人生unstable -- あるハッカー

処理中...