ハクソク

世界を動かす技術を、日本語で。

rsyncアルゴリズム(1996年)[pdf]

概要

  • お送りいただいたデータは、PDFファイルのバイナリデータです。
  • テキスト抽出や内容要約は直接できません
  • PDFの内容を知りたい場合は、テキストデータとして再投稿をお願いします。
  • 画像やスキャンの場合は、OCRツールの利用が必要です。
  • 詳細な内容説明や要約をご希望の場合、本文データの提供が必須です。

PDFデータの内容確認・要約依頼について

  • 現在投稿されている内容はPDFファイルの生データ(バイナリデータ)です。
  • テキスト情報が含まれていないため、内容の確認や要約はできません
  • PDFファイルの中身を知りたい場合は、PDFからテキストを抽出し、そのテキストを投稿してください
    • 例:PDFビューワーで「テキストをコピー」し、貼り付けて投稿
    • 例:OCRツールで画像PDFからテキスト化
  • PDFファイル自体のアップロードや解析はこのチャットでは対応できません
  • テキストデータを投稿いただければ、要約や構造化、翻訳などの対応が可能です。

ご協力のお願い

  • 内容要約や説明をご希望の場合は、PDFの本文テキストを投稿してください
  • PDFが長い場合は、必要なページや抜粋部分のみでも対応可能です。
  • ご不明点があれば、どのような内容か、どの部分に興味があるかを具体的にご相談ください

Hackerたちの意見

よく書けてるし、簡潔だね。この小さな文書は、僕がコンピュータサイエンスを始めた頃の印象を示してる。コンピュータをもっと効率的で賢くする方法、実際の問題を解決するための手段だよ。自称「コンピュータサイエンティスト」や「エンジニア」の人たちが、こういう実際の問題(効率的なファイル同期)に取り組んでくれたらいいのに。新しいReact APIの使い方を学んだり、いろんなサービスに影響を与えてるNextJSのCVEを修正するのに時間を使うのはもったいないと思う。
まあ、当時のシステムのセキュリティレベルは本当にひどかったからね。
自称「マネージャー」が「エンジニア」にこういう仕事をさせることができればいいんだけど、彼らの製品や利益、パフォーマンスレビューには関係ないからね。少なくとも彼らの頭の中では。
最近これをかなり使ってるよ。リモートの仮想マシンをセットアップしてて、すべてのソフトウェアが入ったライブISOを起動するんだ。時々、小さな設定ファイルを変更する必要があって、それが新しい1.7GiBのISOを生成することになるんだけど、その99.9%は前のものと同じなんだ。だからrsyncを使ったんだ。これらのイメージを一日中作業して、1.7GiBのISOを次々とアップロードしてたら、wireguardが送信したのは600MiBだけだって表示して、びっくりしたよ。面白いことに、rsyncは最初にファイルサイズと最終更新時間を使ってファイルが同じかどうかを確認するんだ。これらのISOはnixで作ってるんだけど、nixは再現可能なビルドのために時間を1970年1月1日に設定するから、ISOが次のセクターまでパディングされてると思う。だから、設定ファイルを少し変更したときに新しいISOイメージにrsyncが気づかなかったんだ。--checksumフラグを追加するまでね。
昔は、数MBの毎日の差分をISOからダウンロードしてたんだ。それを昨日のISOに適用してたけど、そのツールの名前は忘れちゃった。自分のマシンでやってたから、親がリモートマシンで更新したい場合は同じようにできるかは分からないな。
もし100GBのイメージだったら—運が良いね!rsyncを使うよりも、毎回最初からコピーした方が早いよ。
BorgBackupみたいなものは、rsyncよりずっと効率的だよ。
面白いタイミングだね、今日NASをセットアップする時にこれを使ったばかりだよ。
面白い事実だけど、rsyncの作者であるアンドリュー・トリッジェルは、Sambaの基礎を築いたMicrosoft SMBを逆アセンブルした人でもあるんだ。彼がどうやってMicrosoftからの訴訟を避けたのかは謎だね。[1] サーバーメッセージブロック: https://en.wikipedia.org/wiki/Server_Message_Block
プロトコルはソフトウェアじゃなくて、相互運用性のために必要なんだ。ヘッダーファイルも同じ。実際には互換性がない競合するソリューションを導き出す「誤用」があると問題が起きるよ。
彼は無料のBitKeeperクライアントも書いてて、ラリー・マクボイと対立したんだ。それが主にgitが生まれた理由でもあるよ。https://blog.brachiosoft.com/en/posts/git/
オーストラリア人は、彼がANUで博士課程の学生だった時にrsyncとSambaに取り組んでいたことを知っておくといいかもね。
>「彼がMicrosoftからの訴訟をどうやって避けたのかは全く理解できない。」 MSは、おそらくLinuxでMSスタックを有効にしていたから、その努力を止めなかったんだろうね。90年代にビル・ゲイツのために準備された内部プレゼンテーションを掘り起こせたらいいんだけど、LinuxがMicrosoftにとって脅威になる可能性を評価してたんだと思う。彼らはLinuxがWindowsマシンと話す理由を持つことを嬉しく思ってたんじゃないかな。
最初は、SAMBAが古いプロトコルだけを実装している限り、MSは気にしてなかったんだ。でも、相互運用性がもっとお金を生むことに気づいて、彼と彼のチームをレドモンドに招待して、MSのエンジニアと一緒に最新のプロトコルバージョンを理解するために一週間働いたんだ。あ、待って、EUに強制されたからだった。 https://www.theregister.com/2007/12/21/samba_microsoft_agree...
彼はフレンチカフェの例えでそれを説明してるよ: https://download.samba.org/pub/tridge/misc/french_cafe.txt
: https://github.com/google/cdc-file-transfer
それはMacOSの現在のバージョンでもあるね。ただ、samba版のrsyncとはあまりうまく連携しないみたい。OpenBSDの実装はプロトコルのバージョン29に制限されてるようだし。MacOSでLinuxコンピュータからデータを引っ張ると、プロトコルバージョンを29や28に設定してもハングすることがあったよ。私が解決したのは、MacOSでsambaのrsyncプログラムに切り替えることだった。
rsyncは僕のお気に入りのプログラムの一つ。毎日使ってるよ。CLIはちょっとクセがあるけど(例えば、末尾のスラッシュとか)、慣れれば理解できる。いつも同じフラグを使ってる:`-avmLP`、ドライラン用に`-n`もね。試してみたい代替品は、Googleが放棄したCDC[1]で、特定のシナリオではrsyncより最大30倍速いって言ってるんだ。フルLinuxサポートのメンテナンスされてるフォークがあるか知ってる人いる?
私も同じだな。rsyncはいつもこうエイリアスしてるよ:'/usr/bin/rsync --archive --xattrs --acls --hard-links --progress --rsh="ssh -p PORT -l USER"' コンピュータ間のファイル転送には、ほとんど他のプログラムを使わないね。
rsyncを使ってお金をもらったのは、もう25年近く前のことだね。ハードリンクを使って、メールサーバーのリモートでバージョン管理されたバックアップを効率よく取ることができた。それで、そのメールサーバーはmaildirを使ってて、maildirに不慣れな人のために言うと、各メールメッセージがディスク上の別々のファイルなんだ。だから、何千ものファイルが入ったフォルダがたくさんあった。さらに、毎日/毎週/その他のバージョンのためのハードリンクもね。当時、こういう使い方をすることに対して非常に声高に反対していた人たちがいて、ファイルシステムの虐待だと例えてた。もしそれが馬鹿げているなら、ハードリンクの使い方はその馬鹿げたことをさらに倍増させたかもしれない。多分、その時はあまり賢くなかったんだろうけど、実際にそれを組み合わせるのは楽しかったし、rsyncが特に遅い(256kbps?)DOCSIS接続の間で自動的に文句も言わずにこの仕事をこなすのを見るのはすごく驚きだった。ちゃんと動いてたよ。何かの理由で過去に戻りたいときは、情報がちゃんと向こうにあって、適切な粒度で存在してた。cronジョブとrsync、あとはちょっとしたbashスクリプトで自動化してた。
> たくさんのフォルダに何千ものファイルが入っていた もしまたこんなことをする必要があったら、rsyncを並列化する方が早いことが多いよ。fpsyncっていうツールがそれを提供してる: https://www.fpart.org/fpsync/
セクション6にはこう書いてあるね。「Linuxカーネルソースのtarファイル... バージョン... 1.99.10のサイズは約24MB... 2.0.0リリースの2441ファイルのうち、291ファイルが変更された」って。Linuxが2441ファイルしかなかったなんて、コードを新しいバージョンにパースできたなんて、全然想像もしてなかったよ。そんな時代はもう過ぎ去ったね。
1996年って、Unixの歴史からするとそんなに昔じゃないけど、Debianのコンピュータでブラウジングしてると、(Unixから派生したものだけど、BSDもオリジナルのUnixじゃないし)長い伝統があるものを使ってるって知るのは楽しいね。
ブロックデバイスでも同じことをしたいなら: https://github.com/rolffokkens/bdsync これを使って、サイトがダウンしたときに再構築が難しいけど、開発者をすぐに仕事に戻すために重要な仮想マシンのバックアップを取ってるよ。まずVMのLVMスナップショットを取って、それをbdsyncでバックアップサーバーに複製して、そこからBackblazeに複製して、最後にスナップショットを削除してる。