Fork長南です。
こんなにたくさんの翻訳をするには、どんなに時間と労力が必要だったでしょう。
それを思うと、たいへん心苦しいのですが、この e2fsprogs の翻訳は、
私としては採用できません。全部を読んだわけではなく、chattr.1, libblkid.3
e2fsck.conf.5, mke2fs.conf.5, mke2fs.8 などを読んだだけですが、
かなり間違いがあるからです。ご自分で何度か見直しをしてから、再投稿して
くださいとお願いするよりありません (それでも、下に述べるようにバージョンの
問題があるのですが)。
もっとも、上に「私としては」と書きました。私以外にもコミット権を持って
いる方がいらっしゃいます。そうした方が「ほぼ公開のレベルに達している」と
判断して、問題点に手を入れてくださるなら、それはそれで結構だと思います。
佐藤さんはしっかりした翻訳をなさる方だと思っていました。それが、今回は
どうなさったのですか。原文が長すぎるか、量が多すぎるかするせいで、
ついつい荒っぽくなってしまったのでしょうか。
かなり間違いあるとか荒っぽいとか、主観的なことを言われても、納得ができない
でしょうから、いくつか例を挙げて簡単に説明します。
1) マニュアルのバージョン選択のこと。
この 1.42.1 のマニュアル原文は、出来のよくないバージョンです。
おそらく、ext3 から ext4 の過渡期に書かれたバージョンで、書き換えが
不十分なのだと思います。ですから、原文に誤りがあります。ちょっと見ただけでも
二つほど見つかりましたから、もっとたくさんあるのではないかと思います。
○ mke2fs.conf.5: Description の [fs_types]:
Contains relations which define defaults that should be used for
specific filesystem types. The filesystem type can be specified
explicitly using the -T option to mke2fs(8).
特定のファイルシステムタイプで使用されるデフォルトを定義するリ
レーションを含む。ファイルシステムタイプは mke2fs(8) の -T オプ
ションで明示的に指定できる。
"-T" オプションは、usage type (利用タイプ、用途タイプ) を指定する
オプションで、ファイルシステムタイプを指定するのは "-t" オプションです。
○ mke2fs.conf.5: THE [fs_types] STANZA の flex_bg_size:
... options This relation specifies additional extended options ...
... options このリレーションは、mke2fs(8) で扱われる追加の拡張オプションを
設定する。
この "options" は見出し (つまり、flex_bg_size と同格なリレーションの名前)
です。より新しいマニュアルと比べてみてください。
2) ext4 の新機能に関わる問題。
上でも言いましたが、このバージョンのマニュアル原文は出来が悪い。それでも、
翻訳を公開する価値があるとしたら、現在の翻訳バージョン 1.39 と比べて、
こちらは ext4 についての説明があることでしょう (もちろん、もっと新しい
バージョンの方がいいに決まっていますけれど)。
ところで、佐藤さんは ext4 についてお詳しいのでしょうか。もしお詳しく
なく、調べてもイマイチよくわからない箇所があるのならば、この ML などで
ご自分から質問するなりなさって、そのへんを詰めておく必要があるのではないか
と思います。
私は ext4 について技術的、理論的なことは、ほとんど何も知らないのですが、
それでも以下の extent や flex_bg についての訳には、疑問を感じます。
○ mke2fs.8: -O オプションの extent の項:
extent Instead of using the indirect block scheme for stor‐
ing the location of data blocks in an inode, use
extents instead. This is a much more efficient
encoding which speeds up filesystem access, espe‐
cially for large files.
inode のデータブロックの場所を格納するために、間接ブ
ロックスキーマを使うのではなく、エクステントを使
う。これはエンコーディングをより効率的にするので、特
に大きなファイルについて、ファイルシステムアクセスを
スピードアップする。
encoding って何ですか。具体的なプログラムの書き方くらいの意味ですか
scheme (スキーム) と schema (スキーマ) は違います (語源は同じですけれど)。
また、原文は、「これ (extents 使用) は、ずっと効率の良いエンコーディング
であり ...」と言っているのだと思います。でも、それ以上の問題は、"in an inode"
のかかり方です。訳文は、ちょっとわかりにくい思います。
ここは、くどい説明をするなら、「inode が管理しているファイルのデータブロックの
位置 (存在する場所) を inode に書き込む際に (記録するのに、登録するのに)
間接ブロック方式を使わず、エクステント方式を使用する」という意味ではないでしょうか
(scheme を取りあえず、「方式」としました。extent の方は、"use extents" と
複数ですから、厳密には「エクステントというもの」なのかもしれません)。佐藤さんの
お訳も、結局同じことを言っているのかもしれませんが。
# なお、extent feature については、手元の e2fsprogs version 1.43.4
# では、ext4(5) という新しいマニュアルに説明が移っていて、より詳しい説明が
# なされています。私にはよく理解できませんけれど。
○ mke2fs.8: -O オプションの flex_bg の項:
flex_bg
Allow the per-block group metadata (allocation bit‐
maps and inode tables) to be placed anywhere on the
storage media. In addition, mke2fs will place the
per-block group metadata together starting at the
first block group of each "flex_bg group". The
size of the flex_bg group can be specified using the
-G option.
ブロックごとのグループメタデータ (アロケーションビッ
トマップと inode テーブル) をストレージメディアの任
意の場所に置けるようにする。さらに mke2fs はブロック
ごとのグループメタデータを、各 "flex_bg group" の最
初のブロックグループとともに置くこともできる。
flex_bg グループのサイズは、-G オプションで指定できる。
"per-block group metadata" は、確かに素直に読めば、「ブロックごとの
グループメタデータ」なんですが、ここでは「ブロックグループごとのメタデータ」
と読まなければ、意味が通らないのではないでしょうか。アロケーションビットマップ
や inode テーブルは、ext3 ではブロックグループごとにあるものですし、
-G オプションの説明にはこんなことが書いてあります。
Specify the number of block groups that will be packed together
to create a larger virtual block group (or "flex_bg group") in
an ext4 filesystem. This improves meta-data locality and per‐
formance on meta-data heavy workloads. The number of groups
must be a power of 2 and may only be specified if the flex_bg
filesystem feature is enabled.
ですから、次のようなことを言っているのだと思います。
ext4 では、ブロックグループをいくつかまとめてより大きな仮想ブロックグループ
(すなわち flex_bg group) を作る。一つにまとめるブロックグループの数は、
"-G" オプションで指定する。"flex_bg" feature を指定すると、
そのまとめられる方の各ブロックグループのメタデータをメディアの任意の場所に
(と言っても、flex_bg group 中なんでしょうけれど) 置けるようになる。
なお、その際、mke2fs(8) は、そうしたブロックグループごとのメタデータを
一箇所にまとめ、各 flex_bg グループを構成する最初のブロックグループ
(のメタデータ) から順番に並べて配置することになる。
3) 構文解釈、あるいは文脈解釈の問題。
○ e2fsck.conf.5: THE [options] STANZA の accept_time_fudge:
Historically this was usually due to some distributions having
buggy init scripts and/or installers that didn't correctly
detect this case and take appropriate countermeasures. However,
it's still possible, despite the best efforts of init script and
installer authors to not be able to detect this misconfigura‐
tion, usually due to a buggy or misconfigured virtualization
manager or the installer not having access to a network time
server during the installation process. So by default, we allow
the superblock times to be fudged by up to 24 hours. This can
be disabled by setting accept_time_fudge to the boolean value of
false. This setting defaults to true.
歴史的にいくつかのディストリビューションでは、init スクリプトに
バグがあったり、インストーラがこのようなケースを検知でできなかっ
たり、適切な対策が打たれていない場合がある。しかも、init スクリ
プトで努力しているにも関わらず、インストーラの作者がこのような間
違い設定を検知できていなかったり、仮想化マネージャにバグがあった
り間違い設定があったり、インストーラがインストール過程でネット
ワークタイムサーバにアクセスしないといった可能性がある。そのた
め、デフォルトでスーパーブロックの時間を、24時間までごまかす
(fudge up) ことができる。これは accept_time_fudge 設定をブール値
false に設定することで可能になる。この設定はデフォルトでは true
である。
私の試訳を挙げておきます。"we allow the superblock times to be
fudged by up to 24 hours" の部分は、「UTC とローカルタイムの混乱を
気にしない」という解釈で訳していますが、違うかもしれません。
従来、こうした事態が起きるのは、たいていの場合、ディストリビューションの
中には init スクリプトやインストーラにバクがあるものがあって、そうした
ものがこのようなケースを正しく検出せず、適切な対策を取らないせいだった。
しかしながら、init スクリプトやインストーラの作者たちが最善の努力をして
いる場合でも、こうした誤設定を検出できないことが、やはり起こりえる。それは、
多くの場合、仮想化マネージャにバグや設定の誤りがあったり、インストーラが
インストールプロセス中にネットワークタイムサーバにアクセスできなかったりする
せいなのだ。そこで、デフォルトでは、スーパーブロックの時刻がおかしくても
24 時間までなら大目に見るようにしている。この動作は、accept_time_fudge
をブール値 false に設定することによって無効にすることができる。この設定は
デフォルトでは true である。
○ e2fsck.conf.5: THE [options] STANZA の broken_system_clock:
The e2fsck(8) program has some heuristics that assume that the
system clock is correct. In addition, many system programs make
similar assumptions. For example, the UUID library depends on
time not going backwards in order for it to be able to make its
guarantees about issuing universally unique ID's. Systems with
broken system clocks, are well, broken. However, broken system
clocks, particularly in embedded systems, do exist. E2fsck will
attempt to use heuristics to determine if the time can not be
trusted; and to skip time-based checks if this is true. If this
boolean is set to true, then e2fsck will always assume that the
system clock can not be trusted.
e2fsck(8) プログラムはシステムクロックが正しいと仮定するいくつか
のヒューリスティック (heuristic) な方法を持っている。さらに、多
くのシステムプログラムも同様の仮定をしている。例えば UUID ライブ
ラリは UUID (universal unique identifier: 汎システム的に他とは重
ならない識別子) を発行することを保証するために、時間が巻き戻らな
いことに依存している。しかし、特に組み込みシステムでは、システム
クロックが壊れている場合がある。e2fsck はこのリレーションが true
の場合、時刻が信用できないと仮定するヒューリスティックな方法を
使って、時刻ベースのチェックをスキップする。このブール値を true
に設定すると、e2fsck はシステムクロックが信用できないと常に仮定
する。
これも私の試訳を載せておきます。私は heuristics というのがわかっていません。
それから、"if this is true" の "this" の解釈が違います。
e2fsck(8) プログラムはヒューリスティックな方法をいくつか装備しているが、
そうしたものは、システムクロックを正確であると見なしている (「システム
クロックが正確であることを前提にしている」という訳もありそう)。ちなみに、
システムプログラムには、同様の想定をしているものが多い。たとえば、UUID
ライブラリは、汎システム的にユニークな ID (universally unique ID)
の発行を保証できるようするため、時間が巻き戻らないことを当てにしている。
システムクロックが狂ったシステムは、それはまあ、壊れているとしか言いよう
がない。しかし、システムクロックが狂っているということは、特に組み込み
システムでは、ままあることである。e2fsck はヒューリスティックな方法を
用いて、時刻が信頼できないかどうかを判断しようと試みる。そして、信頼
できなければ、時刻ベースのチェックをスキップする。このリレーションの
ブール値を true に設定すると、e2fsck は常に、システムクロックを信頼
できないと見なすことになる。
どちらの例についても、文章の論理や、言葉がどうつながっているかに注目して
ください。
mount や sudo の翻訳をなさった佐藤さんが、こんな読み違いをするなんて、
信じられませんでした。それで、「長すぎるか、量が多すぎるかするせいで、
つい荒っぽくなったのでは」と書いたのです。
佐藤さんほどの経験のある方なら、マニュアルの翻訳で大事なのは、内容の正確さと、
それを読者にわかるように伝えることだ、と分かっていらっしゃると思います。
そのへんの丁寧さが、自分用のメモと、他人に読ませる (言い換えれば、世間に
公開する) 翻訳とを分かつところでしょう。というわけで、私としては、もう少し
丁寧に訳していただきたいと思うのです。
見直しをなさるときのために、気が付いたことを二つほど書いておきます。
一つは、feature の訳です。前の翻訳では、「特性、属性」でしたが、今回は
"feature" で済ましていらっしゃるのですね。一理あると思います。
しかし、まだ「特性、属性」の残っているところがあります。
もう一つは、"a power of 2" という表現があちこちに出てきます。
「2 の乗数」とお訳しになっていますが、「2 の累乗」です。「乗数」と
「累乗」は、厳密には別のものでしょう。
追伸:
目下体調を崩していて、まとまったことがほとんど出来ません。投稿の管理やチェックを
他の方にやっていただけると助かります。
--
長南洋一