| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
リンク: daemon3: 「第５章 メモリ管理」の話題.
今手元に原書は無いのですが、スラブアロケーターの仕組みを考えると誤植だと思います。
p188 第2パラグラフ
誤
ゾーンアロケータは、.....略....
解放して後の*最*利用のためにゾーン...
正
ゾーンアロケータは、.....略....
解放して後の*再*利用のためにゾーン...略...
ありがとうございます。
誤植というと印刷屋さんのミスのようですが、元の原稿が間違っているので翻訳のミスです。翻訳原稿から整形用ファイルを自動生成しているので当然ですが。
他の部分も調べた結果、「最利用」という言葉が出てくるのはここだけでした。ちなみに「再利用」は35ヶ所です。
そのパラグラフ内でそれ以前に書かれた内容を参照しているのであろうと思います。次の文には、割り込みがシグナル処理を意味することが間接的に述べられています。３．１２５ページ、下から２１，２２行目「休眠状態を割り込み可能にするかどうか、・・・」とありますが「休眠状態を割り込み可能にする」とは、具体的にどういうことでしょうか？意味を理解できませんので、教えて頂けないでしょうか？お願いします。
能動態と受動態の違いに関して言えば、そう読み替えて頂いて差し支えないだろうと思います。原文はこうです。ページ１２７、上から４行目「取得できなかった資源を要求してブロックした場合、・・・」とありますが、この意味は、「資源を要求して、その資源が取得できずにブロックされた」ということだと思うのですが、それでよろしいでしょうか？もし、よろしければ原文を教えて頂けませんか？お願いします。
When a thread executes for the duration of its time slice or when it blocks because it requires a resource that is currently unavailable, the kernel finds another thread to run and context switches to it.もっとも僕は著者ではありませんので、著者の意図をお知りになりたいのであれば直接お尋ねください。
すみません、これ誤訳です。原文は、２．１２５ページ、下から１８、１７行目「たとえば、ディスク入出力を待つスレッドはシグナルを無視してブロックする」は、「例えば、ディスク入出力を待っているスレッドは、受け取ったシグナルを無視してブロックされる」の方が日本語として解り易いのではないでしょうか！
For example, a thread waiting for disk I/O will sleep with signals blocked.なので、
たとえば、ディスク入出力を待つスレッドはシグナルをブロックして休眠する。もしくは
たとえば、ディスク入出力を待つスレッドはシグナルを無視して休眠する。ですね (多分訳した時の気持ちは後者)。 千住殿の流儀では「シグナルをブロックされて」とすべきかもしれませんが。
一番左の箱でしょうね。ページ１２１、図４－１ プロセス状態について、お尋ねいたします。 この図で、プロセス構造体は、どこの部分でしょうか？ ページ１２１、下から9行目にも「プロセス構造体は、すべての副構造体を直接あるいは間接的に参照する。ユーザ構造体は、・・・」と記載されているのですが、図４－１中には、何の記載もありません。 投稿： 千住 鼎（せんじゅう かなえ） | 2006-05-29 04:28
リンク: daemon3: 第４章 ps.
１．１２４ページ、下から４行目「－カーネル内でイベントを待っている最中ー」となっていますが、「－カーネル内でイベント待ち状態ー」が、日本語としては解り易いのではないでしょうか！
２．１２５ページ、下から１８、１７行目「たとえば、ディスク入出力を待つスレッドはシグナルを無視してブロックする」は、「例えば、ディスク入出力を待っているスレッドは、受け取ったシグナルを無視してブロックされる」の方が日本語として解り易いのではないでしょうか！
ご意見、ありがとうございます。修正すべきというご指摘でしょうか? その必要はないかなあという印象ですが。
「ブロックされる」と「ブロックする」の使い分けは、特に決まったルールがあるわけではありません。英文では受動態が多用されるので、それを全部受動態で訳しているとどうも日本語として締まらない文章になってしまうので、能動態に訳している場所は多数あるはずです。
リンク: daemon3: 第４章 ps.
ページ１２３、下から９行目「・・・、イベントを待ってブロックされているスレッドは・・・」とありますが、これは「・・・、イベント待機でブロックされているスレッド・・・」となるのが正しいのではないでしょうか？ 投稿： 千住 鼎（せんじゅう かなえ） | 2006-05-28 12:22
僕には両者の違いがわかりません。どの部分が間違っているというご指摘でしょうか?
リンク: daemon3: 「第３章 カーネルサービス」の話題.
私はBSDの一部を改造したりしており、また若い人のための解り易いOS教科書を長年捜し求めているのですが「帯に短し襷に長し」で、なかなかめぐり合いません。多分、情報が階層的でなく、動きをイメージできる絵が少ないのが原因だと思います。それで、本書を土台にして、私が望むOSの教科書を作ってみようと思い、何処が解り難いかを一つ一つ洗い出しているところです。従いまして、今後も同様のご質問を致しますが、よろしくお願いいたします。
やりがいのある目標ですね。是非頑張ってください。
著者の前書きにも書いてあったと思いますが、この本はオペレーティングシステムの教科書として書かれてはいないので、メインの教科書として使うのには適していません。完結した本を作るのはかなり大変なので、本書を参照しながら、足りない部分を補って読み進めていけるようなものがあると面白いかもしれませんね。その場合どちらが副読本なのかよくわかりませんが。
ページ１２２、上から６行目、「ｐｓの結果」、11行目、「ｐｓのリスト」 という記述がありますが、「このｐｓ」の意味は何でしょうか？教えて下さい。よろしく 投稿： 千住 鼎（せんじゅう かなえ） 2006-05-22 22:08
これは Unix の ps コマンドのことです。
原文では両方とも ps listing ですが、読みやすさを考慮して訳し分けたんだと思います。
千住鼎様よりのコメント：
> 1．８９ページ、下から1行目、
> 「何か特定のプロセスが走っていることを・・・」と有りますが、
> これは、多分原書では「ｒｕｎ」という単語を使っているから「走って」と訳されたのでしょうが、日本語としては「実行して」と訳した方が理解し易いと思います。
ありがとうございます。
全体で『プロセスが実行』は３２箇所あるのに対して『プロセスが走』は１箇所しかないので、普通なら実行と訳しているところです。しかも文章が下手なせいで、この run は２回訳していますが、２回目は実行にしてますもの。何かの気の迷いで実行が重なるのを嫌ったという可能性もありますが…
『プロセスが走る』は口語では普通に使いますし意味もわかります (と思う…)。もし増刷時同じフィルム内に他に修正箇所があれば直す程度の対応でいいのではないかと考えていますが、それでよろしいでしょうか。
出版社を通じて同じ指摘を受け取っています。ちょっと忙しかったもので、つい返事を遅らせてしまっていますが、ひょっとして同じ方でしょうか?
リンク: Amazon.co.jp：BSDカーネルの設計と実装—FreeBSD詳解: 本
Jason 氏によるレビューが載ったよ。
彼は以前からの知り合いなので提灯ぽくはあるけど、前著にもレビューを書いているので全面的に提灯なわけでもあるまい。『数ヶ月集中的に行った』というのは間違いではないが、こう書かれると２〜３ヶ月で翻訳できちゃったみたいな印象を与えるようで気が引ける。そんな実力はない。実際には１０ヶ月程度かかって、そのうち４ヶ月くらいは無休で働いたというのが真相。『IPv6の実装』の部分は間違いだなあ。内容的には『改善』よりも少しマシになっているかとも。
昨年末よりプライベートでイベントが多かったため、すっかり休筆してしまっていますが、売り上げ増のためにも、もう少し書くことにしよう。いずれ増刷もするかもしれないので修正情報も集めなければ。と、昨日エンケンの『不滅の男』を観て、生エンケン様も拝んで少し元気が出てきたところで決心するのである。DVDも買わねば。
あと、121ページの下から8行目の「考古学的価値」と いうのはちょっと直訳過ぎるかと。というコメントを頂きました。 原文と訳文はこう。
The user structure remains primarily as a historic artifact for the benefit of debuggers.本当に直訳すると「歴史的遺物として」というところか。よく憶えていないが、それだと全然役に立たないようにも思えるので、少し有用性を意識させる文にしようとしたのかもしれない。
ユーザ構造体は、主としてデバッグ上の都合を満たす考古学的価値のために残されている。
完成した日本語版に関する話題を書くためのカテゴリを用意しました。少し読み返す気にもなってきたので、今後少しずつ内容を書いていきたいと思います。各カテゴリに１つ記事を用意したので、誤りを発見したり、意見や要望等ありましたら、そこにコメントしてください。必要に応じて独立した内容に移します。
「第１４章 起動と終了」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第１３章 ネットワークプロトコル」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第１２章 ネットワーク通信」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第１１章 プロセス間通信」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第１０章 端末デバイス管理」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第９章 ネットワークファイルシステム」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第８章 ローカルファイルシステム」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第７章 デバイス」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第６章 入出力システムの概要」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第５章 メモリ管理」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第４章 プロセス管理」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第３章 カーネルサービス」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第２章 FreeBSD の設計概要」についての意見や間違い等がありましたら、こちらにコメントしてください。
「第１章 歴史と目標」についての意見や間違い等がありましたら、こちらにコメントしてください。
「まえがき」および全体についての意見や間違い等がありましたら、こちらにコメントしてください。
先週はついにランキング外に落ちてしまいました。注目していた脱オタクファッションガイドは1位になってる。
作業が終わった後はしばらく見たくもない気分なので、できあがった本はほとんど読んでいない。売れ行きが落ちてきたし、時間も経ったので、販促活動を兼ねて読みながら中身の話でも書いてみるか。悪い評判も見当たらないが、いい評判もないので、あまり話題にもならなさそうだし。適当に突っ込みどころのある本の方が売れるんじゃないかと思ってしまったりもする。
今のところ誤字脱字を含めて、間違いや不備に関する報告が一つも届いていないのが不思議である。自分で気づいたのは、359ページの図8-12で、真ん中下の "fs=" の部分のフォントがおかしいのと、478ページのレイアウトがずれていることくらい。まあ、読んでないので見つかるわけがないのだが。
書泉グランデ 16位 (2005年10月31日〜11月6日) ちょっと持ち直した。
cbook24 14位 (2005年10月31日〜11月06日)
Amazon 5,256位 (11月10日現在) (OS関連4位)
個人的に注目したのは、グランデコンピュータ関連10位の脱オタクファッションガイドか。売り場で分類されるのですかね。萌えるダイエットもおすすめらしい。
daemon3: 森博嗣の TOOLBOXと関係あるはずがないのだが、偶然家人が買ってきた
を読んだ。ディの場合は、ギィとかピィとかとは少々状況が異なる。一般には明らかにデーやデイとは違う読み方を意図した記法だからだ。まさか本当に「バースディ」と読んでほしくてこういうタイトルを付けているとは思えないんだが、ビジュアル重視ということなんだろうか?
Googleで「バースディ」を検索すると「バースデー」も「バースデイ」も全部引っかかる (6,530,000件)。このうち、どちらも出てこないのは264件。
リンク: LunchTimeException: BSDカーネルの設計と実装
実践的な本てどんなのだろう。OSだったら、設定の仕方とかチューニングの方法とかを解説しているようなもんなのかな。それとも、OSなんかよりもアプリケーションの使い方とか、プログラミング技法とかを勉強した方がいいという意味なんだろうか。
考えてみると、僕は今まで実践的な本をほとんど読んだことがないことに気がついた。強いて挙げれば『実用Perlプログラミング』くらいだろうか。これを除いてPerlはマニュアルしか読んだことないし、CもK&Rしか知らない。マニュアルセット以外に読んだUnixの解説は、石田先生のbitの連載くらいか (Unix Time-Sharing System などの論文はマニュアルに含まれる)。セキュリティの本も読んだことないなあ。初期のファイアウォールの論文なんかは読んだけど。
読まなかった理由は2つある。1つは、必要な時にはそんな本が存在しなかったこと。もう1つは、あってもそれを読もうと思わなかったこと。1番目の理由が支配的なので2番目の理由はあってもなくても大差ない。あっても読まないのは、本質を理解したいからだと言っておけばいいかもしれないが、単に他人の言うことを信用しない質だけなのかもしれない。実践的であるからには、そこに著者の主張が含まれているはずだ。自分の領域については、他人の意見なんか信じられないし、そんなもの読んでる暇があったら自分で考えた方がいいのだ。当然のことだが、他人のこういう主張も信じちゃいけない。
書泉グランデ 2位 (2005年10月17日〜23日)
cbook24 7位 (2005年10月17日〜10月23日)
楽天 PC・システム開発1位 (10/19 ‐10/25)
楽天 21位
# 楽天のランキングていろいろあってよくわからん。
# 発売前に注文した Winnyがまだ届かないのはどういうこと? 配送予定日は 10/7-9 なのに。
アマゾンにやっと画像が載りました。ちょっと黄色っぽいぞ。現在5010位。
iTakahiro's D - BSDカーネルの設計と実装--FreeBSD詳解--で曰く:
> 400ページを超える本は 2分冊にするとかって出来ないのかなあ。
>
> どうせ特定の人しか買わないんだから、ちょっとカッコよいボックスに入れて売れば、1000円ぐらい上乗せしても買うと思うんだけど。
分冊については出版社に提案しました。パートを 1+2, 3, 4+5 に分割すると、分量がほぼ三等分になって持ち運びに便利なサイズになります。それをボックス装丁にした場合で見積もりを取ってもらいました。そしたら、販売価格が1500円高くなり、増加分のほとんどは箱代なのだそうです。
500円増くらいならいけるんじゃないかと思ったのですが、さすがに1500円はきつそうなので諦めました。ボックスにすると外形が変わってしまい、平積みしにくくなるので営業的にも不評だそうです。まあ、考えれば何か手はあったのかもしれませんが、そんな暇があったら中身を良くした方がいいので断念したのでした。
この本は電子データで作業しましたが、印刷物で監訳する時なんかは、1章ずつ原書を切り離して持ち運びます。本が可哀想な気もしますが、ただ積んどかれるよりは幸せかも :-)。
が届いた。最初に買ったMacがSEなのも、今使っているのがPowerBook G4なのも、家族全員Macユーザなのも、奥さんがCubeを使っているのも一緒だ。でも、僕は左手でマウスは使えないしミステリーも書けない。
ところで、この本には「エネルギィ」という表記が出てくるが、これはどういう意図なんだろう? 「エネルギー」じゃ嫌だったんだろうな、きっと。だったら「エネルギ」でもよさそうなもんだが、それじゃ短すぎるので中間を取ったんだろうか。僕は「ユーザー」よりも「ユーザ」と書くのを好むけど、別に「ザ」でちょん切りたいわけじゃない。こういう時、森博嗣さんは「ユーザァ」と書くのだろうか。「エネルギイ」というのもありだが、こうすると下手すると最後のイにアクセントが来る可能性もある。ひょっとして「エネルギー」と書くと名古屋の人は「ギ」にアクセントを置いちゃうかもしれなくて、それを嫌ったんだろうか。「エネルグィ」であれば、好き嫌いどうあれ、どう発音して欲しいかという意図は伝わる。
そういえば「日本ファジィ学会」というのがある。あれも、意図はわかんないけど。
弾さんが、原書に対するコメントとして404 Blog Not Found:Price and Value of Due Processで『本書で学べる一番いいところは、BSDではなくて、その設計思想だ』と書いてくれている。訳者まえがきの最後に『冒頭で BSD も大きく変化しているのだと書いたが、基本的な姿勢は少しも変わっていない。技術的内容はもちろんだが、本書全体を通じて感じとれる BSD 流の文化と精神がなるべく多くの方に伝われば…』と書いたように、まったくその通り。さすがである。
リンク: Yahoo!ニュース - ランキングによれば森博嗣の TOOLBOX を押さえて週間一位らしい。森博嗣さんは好きな作家であるだけに光栄である。ここにも書いたように、翻訳作業中はずっと森博嗣のS&Mシリーズを読んでいたのだ。しかも、この本めちゃくちゃ面白そうだ。両方買うべし。
アマゾンのランキング。今まで5桁しか見たことなかったような気がするので、なんか嬉しい。
リンク: さいとの備忘録:『BSDカーネルの設計と実装』購入 を見ると、もう書店に並んでいるということか。18日って聞いたんだけどなあ。なんにせよ、お買い上げありがとうございました。ところで日経BPじゃないよ。
アマゾンは在庫切れになってるけど、予約できたってことは初回配本分が売り切れたってことなんだろうか。
トラックバックってやったことないので試してみた。これでいいのかな?
目次の中に「日本の皆さんへ」という項目があることに気づかれた方もいるかと思う。これは、日本語版のために著者から特別に頂いた文章である。実は、この部分は敢えて翻訳せずに、著者からもらった文章を原語のまま掲載している。せっかくなので、著者の言葉を直接読んでもらいたいと思ってこのような形にした。ほとんどの読者はおそらく原文のまま読めると思うし、もしそうでなくてもちょっと頑張って読んでみて欲しいし、もしどうしても読めなかったとしても、本来は含まれていない文章なのだから読まなくても本質的な問題はあるまいという判断である。
決して手抜きじゃないのですよ。信じて。
Tiger にしたら Safari で★と☆の大きさが全然違って、こんな風に見える。
夕べはなかったけど、今朝見たらアスキーのウェブにも出てました。
書店発売は10月18日に決まったそうです。
未本誌は金曜日にできたらしいのですが、先週末から東京を離れているため僕はまだ見ていません。
取り急ぎ、ご報告まで。
先週の金曜日になんとか入稿しました。今は印刷所でフィルムを焼いているところなので、よほどのことがない限り今後の修正はないと思います。どうもご協力ありがとうございました。
更新が少なくてすみません。入稿直前です。
参考文献のリストを
daemon3bib.html
に作りました。こちらで調べた限りの邦訳情報を入れていますが、もしここに載っていない情報をお持ちでしたらお知らせください。雑誌に収録されているものなどは、特に落ちている可能性があります。
ただ、時間的余裕がほとんどなくて、9/14(水曜日)の夕方までに頂ければ、反映できると思います。
間に合わなかった分については、第2刷以降で対応します (出ればですが :-)。
page 581
The model of computation supported by the cryptographic subsystem is one of job submission and callbacks where users submit work to be done to a queue and supply a pointer to a function that will be called when the job is completed.暗号サブシステムがサポートする計算モデルは、ジョブサブミッションとコールバックに基づくもので、ユーザは実行しようとする作業をキューに投入すると同時に、作業が完了した際に実行する関数のポインタを登録する。
かなり力尽きていて、これ以上なんとかしようという気にならない。
529 ページ、TCP Connection Status
They serve to frame the data that are transferred during a connection so that not only the data but also their extent are communicated reliably.これらは、接続によって転送されるデータの枠組を規定し、データそのものだけではなく、その填充に関する情報を確実に交換できることを保証する。
自分ではなかなか妙訳だと思うのが、きっとタイポだと思われるだろうなあ。
extension 【理】 填充((てんじゆう))性《物体が空間を占める性質》
extent 【理】 填充性 (extension) を有するもの
(リーダーズ・プラス)
508ページ
A stream socket's notion of out-of-band data has been defined as the lowest reasonable common denominator.ストリームソケットが採用している帯域外データの概念は、様々な概念の最大公約数である。
前の時も悩んだんだけど、lowest (least) common denominator に対応する日本語は「最小公分母」である。しかし、文章の中では「最小公倍数」と言った方が語感がいい。でも、意味から考えれば「最大公約数」か。
491ページ
"1822 host convention" は「1822ホスト規則」でいいんですかね。
Manyof the requests have been derivedfrom the Internet Control Message Protocol (ICMP) [Postel, 1981] and from error messages defined in the 1822 host (Internet Message Processor) convention [BBN, 1978].多くの要求は、ICMP (Internet Control Message Protocol)および、1822 ホスト (IMP: Internet Message Processor) 規則で定義されているエラーメッセージに由来している。
図表の準備が一応終わった。図が158枚、表が57枚あるので、まとめて日本語に直そうとすると結構大変。しかも、昔やったところなので、内容をよく思い出せなかったりする。表については、TBLから変換しようなどという馬鹿なことは考えずに、最初からEWBで作成。図は xfig か pic で作られているので、ファイルを直接修正する。MacOS 用の xfig がうまくインストールできなかったので、どんな風になるのか確認できないが、後は編集者におまかせ。
見直し作業が滞っていたが、ようやく再開できる。12章と13章が終わったら、索引の作成に入るつもり。
水曜日半日と金曜日半日をかけて troff の原稿を EWB に変換するプログラムを作成。一応印刷可能なところまではできたので、金曜の晩に全体を印刷してみた。やはり、紙になると随分と違う。
この原稿中のマクロを処理するだけなので、本格的なマクロプロセッサを作るつもりなどなかったのだが、やっぱりどうしても必要がでてきて、.de とか .rm とかも実装してしまった。.de を処理する機能を入れると、それまで決めうちで処理していた部分を .de で書き直したくなる無駄な衝動を押さえつつ作業を進める。
作業がらみで cvs の pserver を立ち上げようとしてはまってます。MacOS X (10.3) で上げようとするのがいけないのだろうか...
442ページ、最後のパラグラフ
Throughout this chapter, references to the supporting facilities provided by the network-communication protocols are made with little elaboration.本章全体を通じて、ネットワーク通信プロトコルによってもたらされるサポート機能をごく簡単に参照する。
"with little elaboration" の意味が怪しい。little だから、もっと否定的に訳すべきなのかも。
そもそも "supporting facilities provided by the network-communication protocols" とは、何のことを指しているのだろうか。プロトコルが提供するサポート機能ってなんだ。普通はプロトコルをサポートする機能があるんじゃないのか。
408ページ、9行目
Thus, lease requests can almost always be piggybacked on other RPC requests, avoiding some of the overhead associated with the explicit open and close RPC required by a long-term callback implementation.したがって、ほとんどすべてのリース要求は、他のRPC要求にピギーバックすることが可能で、長期コールバック型の実装で必要となるような明示的なオープンやクローズに伴うオーバーヘッドは発生しない。
long-term callback (implementation) とはなんだろう。ここにしか出てこない。一般的な用語っぽく訳してみた。
# PDF からテキストを切り取ると、ハイフネーション部分は省いてくれるのですね。知らなかった。偉い。
389ページ、2パラ
When running under TCP on an Ethernet, the message may also be broken into up to six packets; however, individual lost packets, rather than the entire message, can be retransmitted.
だから、NFS は UDP よりも TCP で使った方がいいと言っている。
そんなうまいこといくのでしたっけ? slow start とも関係するかな。
13章には、selective ack は実装していないと書いてある。
387ページ、2パラ
At publication time (2004), the NFS version 4 specification is still a draft standard [Shepler et al., 2003]. There are people who are actively working on writing an NFS version 4 implementation for BSD, but it has not yet been tried in FreeBSD.本書の出版時点 (2004年) では、NFSバージョン4の仕様は、依然として提案の状態である。BSD 上の NFS バージョン4実装のための活動を続けているグループは存在するが、FreeBSD 上の実装はまだ行われていない。
現状の確認。
quadratic hash と書いてある部分 (p372, p380) と、quadratic rehash と書いてある部分 (p372, p374) とある。なんか違うのか?
ちなみに quadratic hash の訳語は「二次ハッシュ」。Knuth に合わせてある。
364ページ、3パラ
Each cylinder group must fit into a single filesystem block.それぞれのシリンダグループは、1つのファイルシステムブロックに収まらなければならない。
シリンダグループの方がファイルシステムブロックよりも当然でかい。シリンダグループマップの間違いだろうか。
363ページ、最後
To allow support for filesystem fragments as small as a single 512-byte disk sector, the minimum size of a filesystem block is 4096 bytes.1つの 512バイトディスクセクタをファイルシステムのフラグメントとするために、最小のファイルシステムブロック長は 4096バイトになる。
どうして?
357ページ、4行目
With soft updates, the only inconsistency that can arise in the filesystem (barring software bugs and media failures) is that some unreferenced blocks may not appear in the bitmaps and some inodes may have to have overly high link counts reduced.ソフトアップデートを運用中のファイルシステムで生じる可能性のある不整合は、ビットマップ中に参照されないブロックが現れることと、inode のリンク数が必要以上に増加しまうことだけである (ソフトウェアのバグやメディア障害を除く)。
最後の reduced は、一体いかなる意味か? 文脈的に減りすぎてしまうということはあり得ない。
328ページ、2パラの最後
Interestingly, rename is the one POSIX file operation that should have an atomic update to multiple user-visible metadata structures to provide ideal semantics. POSIX does not require said semantics and most implementations, including FreeBSD, cannot provide it.
最初の文と2番目の分は矛盾してるような気がするのだが、どういう話の流れなんだろう? 何事もなければ要求されるのだが、わざわざ要求しないことが仕様に書かれているということなのだろうか。
ここの話題は、rename システムコールの途中で障害が発生すると名前が2つ残ってしまう可能性があるということ。
327ページ、2パラ
If link counts are being kept conservatively, rename involves at least four disk updates in sequence: one to increment the inode's link count, one to add the new directory entry, one to remove the old directory entry, and one to decrement the link count.常にリンク数の下限を確保するためには、名前の変更は連続する4回のディスクの更新を必要する。すなわち、inode のリンク数を増加させるために1回、新しいディレクトリエントリを追加するために1回、古いディレクトリエントリを削除するために1回、リンク数を減少させるために1回である。
どこからも参照されないファイルを作らないためには、リンク数を減らしすぎてはならない。なので conservatively の訳は、これで多分あってると思うのだが、辞書を見ると「内輪に見積もる」というような意味もある。多めに見積もるのと少なめに見積もるのの、どちらが conservative かって、状況によるよね。
前のページの2段落目にも同じような表現がある。
324ページ、"Soft Updates" の冒頭
In filesystems, metadata (e.g., directories, inodes, and free block maps) gives structure to raw storage capacity. Metadata provides pointers and descriptions for linking multiple disk sectors into files and identifying those files.
ファイルシステムにおけるメタデータ (metadata) (たとえば、ディレクトリ、inode、未使用ブロックマップ) は、未加工の記憶領域に構造を与えるためのものである。メタデータは、複数のディスクセクタからファイルを構成し、それらのファイルを識別するための手がかりを与え意味を定義する。
この pointers and descriptions の意味がどうも釈然としない。
320ページ、下から5行目
The wait channel for process 1 shows that process 2 is sleeping, waiting for a lock to clear, and identifies the pending lock structure as the pending lock (range 9 to 12) hanging off the lf_block field of the second active lock (range 7 to 12).
プロセス1の wait channel を見てプロセス2が休眠しているのがわかるのはおかしくないか。実は、前の版では "process 2 is sleeping" の部分は "process too is sleeping" となっている。つまり『プロセス1もまた休眠している』と解釈すれば筋が通るので、今はそう訳してある。でも英語的にちょっと不自然な気もするのだが、こういう too の使い方をすることはあるのか。
翻訳作業は去年の10月に始めたが、ゴールデンウィークからネジを巻いて、以来完全無休状態で翻訳作業をしている。他の仕事もあるので四六時中翻訳してたわけではないが、この3ヶ月間は、週のうち3〜4日を翻訳作業に当てて来た気がする。
電車に乗っていても座れればたとえ2駅でもラップトップを開いて作業するという状況だが、そうすると不思議なもので、座れずに立っている時間もボンヤリしてるのがもったいない。もったいないので本を読む。暇な時にはそんなに読まないのにね。
270ページ、2個目の黒丸
Aggregation of disks to provide a RAID, mirrored, or stripped logical volume
striped のタイポだろうと解釈し、勝手にそう訳した。
最近のコメント