Soft update?
Kawaguti Ginga
<3988702...@insigna.ie.u-ryukyu.ac.jp>の記事において
ko...@ie.u-ryukyu.ac.jpさんは書きました。
> ディスク側はキャッシュの分は、電源断の場合でも、書込終了を出
> したものに関しては書き込むのが礼儀なんじゃないかなぁ。とか考
> えると、write through な奴が普通なんじゃないかなと。
日立 HGST (旧 IBM)の 180GXP の HDD なんかは HDD 側で
command queueing 相当の処理をするらしいのですが，
これは(write 時にも効いてくれるのなら)必然的に
write through じゃない動作を意味すると思うのですが如何でしょう?
cf.
LSI Logic(AMI) MegaRAID 系列なんかは RAID card の
cache memory の内容を保持するバッテリを積んでいるようです．
MegaRAID i4 という ATA-RAID の安物は説明だけあって
"俺は積んでいないけど" とあります．
(多分 SCSI の本物の MegaRAID にはあるということなんだろう，
と思ってます)
--
∧∧
Zzz.. (- - )⌒⌒⊇～ 川口 銀河
############## gi...@athena.club.ne.jp
NAKAMURA Kazushi
gi...@athena.club.ne.jp writes:
>> ディスク側はキャッシュの分は、電源断の場合でも、書込終了を出
>> したものに関しては書き込むのが礼儀なんじゃないかなぁ。とか考
>> えると、write through な奴が普通なんじゃないかなと。
*BSD系は安全側にwrite throughで使っていたのですが、Linux
は最初からwrite backがデフォルトで使っていて、ビデオキャプチャ
なんかする時は、この違いによる速度差が出てました。FreeBSD
5-currentではとうとうデフォルトでONになってしまいましたが、
4-系列でも、sysctl hw.ata.wc=1を設定するとATA disk
のwrite cacheが有効になって性能向上・危険性増大に設定可能です。
>日立 HGST (旧 IBM)の 180GXP の HDD なんかは HDD 側で
>command queueing 相当の処理をするらしいのですが，
>これは(write 時にも効いてくれるのなら)必然的に
>write through じゃない動作を意味すると思うのですが如何でしょう?
日立もなんだ。5.0Rが出た頃はIBMしか無かったと思いましたが、
Tagged command queueingもサポートしたATA diskも有ります。
5.1Rでもこれの初期値は0なんですが、1に設定してやると
tagged command queueingも有効になります。
他にSCSIの制御の為にcamcontrolというコマンドが有りますが、
atacontrolという似たようなコマンドも出来てます。
--
中村和志＠神戸 <mailto:k...@kobe1995.net>
NAKAMURA Kazushi@KOBE <http://kobe1995.jp/>
- Be Free(BSD), or Die...
Yasushi Shinjo
だいぶ深い話になってきました。
In article <0308010449...@ns.kobe1995.net>
k...@kobe1995.net (NAKAMURA Kazushi) writes:
> Write backな奴は、もうずっと以前から普通になっています。
> *BSD系は安全側にwrite throughで使っていたのですが、Linux
> は最初からwrite backがデフォルトで使っていて、ビデオキャプチャ
> なんかする時は、この違いによる速度差が出てました。
write back という用語がよく分からないのですが、これは、write
しても、ディスク側のキャッシュに書くだけで、実際にはディスク
には書かれないという意味ですか。
共有メモリの一貫性なら、write-through/copy-back というのはい
いんだけど。ハードディスクなら、書き手は１つだから、back は
ないんじゃないかと。
メタデータというと、inodeと、ディレクトリのファイル名ですか。
In article <0307291528...@ns.kobe1995.net>
k...@kobe1995.net (NAKAMURA Kazushi) writes:
> 1.完全に整合が取れた状態。
> 2.メタデータは書かれているが、実体が書かれていない状態。
> 3.実体は書かれているが、メタデータは書かれていない状態。
> 4.メタデータも実体も、両方とも完全には書かれていない状態。
> と有って、1.は問題無いとして、2.の場合はfsck -p で実体の
> 無いファイルをメタデータから消去して、3.の場合はメタデータ
> を持たない実体をlost+foundに移して、ファイルシステムとして
> の整合性を保つことが可能です。4.の場合、ファイルを失う
> だけで済まず、ファイルシステムとしての整合性を失う可能性
> が存在します(Linuxで開発していると結構食らいます）。
> この可能性を無くしたのがSoftUpdateです。見たところ、単純に
> 実体を全部書いてから、メタデータを全部書いて、…というの
> ではなく、メタデータの指す先の実体とか、かなり細かく
> 書込タイミングの制御をしているようです。
タイミングを制御すると、遅くなることはあっても、速くなること
はないと思うんだけど。書込みのタイミングは、ＯＳの上位層から
の要求の順番ではなくて、適当に入れ替えて、ヘッドの位置や回転
待ち時間を考慮して最適化した方が速いと思うんです。それを、
ＯＳの上位層の指示の順番に従えば、最適化ができなくて遅くなる
んじゃないですか。
> そんな訳で、ファイルシステムとして整合性が必ず取れることが
> 保証されるだけで、ファイルを失う可能性は残るので、ジャー
> ナリング一切不要とは思いません。しかも、失うファイルの書込
> タイミングも分からないし。
fsck が速くなるというのは、わかりますけど。
http://www.mckusick.com/softdep/index.html
------------------------------------------------------------
Traditionally, filesystem consistency has been maintained
across system failures either by using synchronous writes to
sequence dependent metadata updates or by using write-ahead
logging to atomically group them. Soft updates, an
alternative to these approaches, is an implementation
mechanism that tracks and enforces metadata update
dependencies to ensure that the disk image is always kept
consistent. The use of soft updates obviates the need for a
separate log or for most synchronous writes. Indeed, the
ability of soft updates to aggregate many operations
^^^^^^^^^
previously done individually and synchronously reduces the
number of disk writes by 40 to 70% for file-intensive
environments (e.g., program development, mail servers,
etc.). In addition to performance enhancement, soft updates
can also maintain better disk consistency. By ensuring that
the only inconsistencies are unclaimed blocks or inodes,
soft updates can eliminate the need to run a filesystem
check program after every system crash. Instead, the system
is brought up immediately.
------------------------------------------------------------
aggregate の所がよくわからないんだけど、
consistency が取れるなら write するけれど、consistency が取
れないなら、write しないで溜める。
という意味ですか。
いくら溜めても、メモリが無くなれば最後は write するしかいな
ので、平均的には特かもしれないけれど、極限状態だと危ないこと
もあるんじゃないかなあ。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
NAKAMURA Kazushi
In article <YAS.03Au...@kirk.is.tsukuba.ac.jp>
y...@is.tsukuba.ac.jp writes:
>だいぶ深い話になってきました。
はい。
>write back という用語がよく分からないのですが、これは、write
>しても、ディスク側のキャッシュに書くだけで、実際にはディスク
>には書かれないという意味ですか。
>共有メモリの一貫性なら、write-through/copy-back というのはい
まあ、だいたいその通りです。現実にはキャッシュに書くだけ or
逆にキャッシュに書かずに直接ディスクにだけ書くということは
ないので、厳密に言うと、
・ディスク側のキャッシュには必ず書く
・その後、ちゃんとディスクに書いてからackを返す。→write through
・データを受取った時点でとりあえずackを返す。実際にディスクに
書くのは後で頃合いを見計らってから。→write back
というつもりで書きました。必ずコピーが残っているのだから、
copy-backという用語の方が適切かも知れませんが。
>タイミングを制御すると、遅くなることはあっても、速くなること
>はないと思うんだけど。書込みのタイミングは、ＯＳの上位層から
そうなんです。lazy-evaluationと同等の御利益を期待して、いかに
うまく遅くするかに知恵を絞っている訳なのですが、
>の要求の順番ではなくて、適当に入れ替えて、ヘッドの位置や回転
>待ち時間を考慮して最適化した方が速いと思うんです。それを、
ええ、BSDのFFSはその辺をカリカリにチューンしていました。いや、
今でもしています（or しているつもりです）。更にディレクトリ間
の相関関係なんかまでも利用して。MINIXですら、bufferをflush
する時、ヘッドのシーク時間が少なくなるように、書込み順を入換え
る、くらいのことはやっていました。
>ＯＳの上位層の指示の順番に従えば、最適化ができなくて遅くなる
>んじゃないですか。
実際にdiskに書込みを指示するのは下位層なので。
問題は、diskが540MBクラスから1GB超になる頃、内周と外周でセクタ
数が異なる可変記録密度方式を採用するようになり、従来のC/H/S
で管理出来なくなったことです。IBM-PCの場合、C/H/Sまとめて16bit
というシバリから1024シリンダ問題も有り、SCSIライクにLBAでアクセス
したいという要求も有って、これ以降LBAでアクセスするようになり、
本当のC/H/Sは外部に見せなくなりました。古いWindowsやDOS
のようにC/H/Sでアクセスしてくる奴は、BIOSが適当にLBAに変換して
くれて、diskは内部でLBAから本当のC/H/Sに変換すると。
＃その変換アルゴリズムがBIOSによって違うことがたまに有り、disk
＃を他のPCに移植すると読めなかったり、RAID I/Fが故障して交換
＃したら、壊れていないdiskを読めないと言って勝手に初期化して
＃くれたりしますが。
従来、BSD UNIXがやっていたような最適化は、diskが内部で勝手に
やるようになってしまいました。BSDがやっていた最適化も可変記録
密度方式には対応していませんでしたし。そしてdiskの外部から見た
速度を向上させるには、
a.外部には、とりあえずackを返す。
b.内部的には、なるべく書込みを遅らせて、書込み順を最適化する。
という風になりました。FreeBSDでは長らく、危険なのでa.は
disableにしていたのですが、速度向上にかなり効果が有るのと、
ヨソ(Linux,Windows)が平気な顔して使っているので、最近enable
になりました。ata(4)を見ると、
hw.ata.wc
set to 1 to enable Write Caching, 0 to disable (default is enabled).
(WARNING: might cause data loss on power failures.)
となっています。割と最近まで、defaultは0でした。ウォーニングにも
有るように、enableだとデータを失う可能性が有ると思います。そして
その失うデータがどれになるのかdisk外部から予測不能なので、Soft-
Updateでも、ジャーナリング不要とは私は思わないのです。もっとも
これがenableだとジャーナリングしてても駄目な気がしますが。
最近だと更に、
hw.ata.tags
set to 1 to enable Tagged Queuing support, 0 to disable (default is dis-
abled). (Only IBM DPTA, DTLA, ICxxxxxxAT, ICxxxxxxAV drives support
that.)
というのも入っています。いつの間にやら、IBM以外のドライブもサポート
されているらしいですが、私は使ったこと無いです。
数年前、fjで話題になったのは、「最近のdiskは内部のC/H/Sを見せて
くれず、勝手に最適化しているのに、*BSDでcylinder groupやら何やら
一生懸命最適化しているのは、もはや無意味では？」という疑問です。
結論として、「*BSDで最適化したファイルはなるべく近くの連続した
LBAに配置されて、そういうLBAでアクセスするファイルはどうやら
disk内部でも近くに配置され、結果的にソコハカトナク効果は有るん
じゃないの。」ということになったように思います。
>fsck が速くなるというのは、わかりますけど。
> consistency が取れるなら write するけれど、consistency が取
> れないなら、write しないで溜める。
>
>という意味ですか。
そうですね。
>いくら溜めても、メモリが無くなれば最後は write するしかいな
>ので、平均的には特かもしれないけれど、極限状態だと危ないこと
>もあるんじゃないかなあ。
そうです。SoftUpdateが登場した時、綱渡り的だと不安がる人が結構
居ました。私も-stableブランチからリリースが２つか３つ出てから
やっと使い始めた口です。でも、SoftUpdateの作業をした人達はこの
極限状態のギリギリのタイミングまで追いかけて安全なように作った
と言っていたと思います。そうすれば、async書込みの速度とsync
書込みの安全性が得られると。
Shinji KONO
In article <0308041657...@ns.kobe1995.net>, k...@kobe1995.net (NAKAMURA Kazushi) writes
> a.外部には、とりあえずackを返す。
> b.内部的には、なるべく書込みを遅らせて、書込み順を最適化する。
> という風になりました。FreeBSDでは長らく、危険なのでa.は
> disableにしていたのですが、速度向上にかなり効果が有るのと、
> ヨソ(Linux,Windows)が平気な顔して使っているので、最近enable
> になりました。
BSD/OS では、システムが飛ぶとviがopenしているファイルが消え
るという楽しい目にながらくあってました。しかも fsck でrecover
できず、exrecover もできないという... しかも、vim じゃなくて
jsteive とか使っていたので、デフォルトで.bakが出来ず、しかた
ないのでshellかぶせて.bak を作るなんてのをやってました。あれ
はなんだったんだ?
OS的ファイルシステム的には、そんなのは危険でもなんでもなく、
ディレクトリの整合性のみが重要なみたいですね。Linux は、そう
いう意味で危ないってのは聞いていたんですけど、それほど問題に
なったことは無かったな。もっとも、そんなに一生懸命使ったわけ
でもないんですが...
HFS+ はどうなのかな...
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
Kawaguti Ginga
<3988730...@insigna.ie.u-ryukyu.ac.jp>の記事において
ko...@ie.u-ryukyu.ac.jpさんは書きました。
> BSD/OS では、システムが飛ぶとviがopenしているファイルが消え
> るという楽しい目にながらくあってました。しかも fsck でrecover
FreeBSD でも遭遇したことがあるような気がします．
(vi 使いではないのですが，"編集中のファイル" の消滅です．
/etc/hoge を編集中の editor を ^Z している状態で
shutdown -r now とかしたらファイルが消えてた...)
> OS的ファイルシステム的には、そんなのは危険でもなんでもなく、
> ディレクトリの整合性のみが重要なみたいですね。Linux は、そう
いや，"のみが重要" は言い過ぎで，それが 最低限 という
ことではないでしょうか．素人的表現では
* (OS 死亡がきっかけで) file system 全体が吹っ飛ぶ => 下の下
* ファイルシステムの整合性は壊れないけど個別ファイルは吹っ飛ぶ => 下
* 吹っ飛ばない程度に守ってくれる => 中
* 復帰時に回復(?)してくれる => 上
* (そもそも OS その他がこけない => 上の上)
みたいな感じで．
# 原理的に金/ハードウェアに依存する部分もあるわけですが．
none
Kawaguti Ginga wrote:
> いや，"のみが重要" は言い過ぎで，それが 最低限 という
> ことではないでしょうか．素人的表現では
> * (OS 死亡がきっかけで) file system 全体が吹っ飛ぶ => 下の下
> * ファイルシステムの整合性は壊れないけど個別ファイルは吹っ飛ぶ => 下
これはどうかなぁ。
個別ファイルといっても、書き換えつつあったファイルそのもの
と、関係ない個別ファイルとでは失われたときの怒りの度合いが
違いませんか？
* (OS 死亡がきっかけで) file system 全体が吹っ飛ぶ => 下の下
* ディレクトリが吹っ飛んで lost+found 送り=> 下の下
* ディレクトリの内容が狂って、名前と中身が食い違う> 下の下
* write open してない個別ファイルが吹っ飛ぶ => 下の下
* 書き換えつつあったファイルは吹っ飛ぶ => 下
* 書き換えつつあったファイルの中身が失われる => 中
* ディレクトリの内容が狂って、消した筈のファイルが残る> 中
* ディレクトリの内容が狂って、消した筈のファイルの残骸が残る
(が、fackで修正される)> 中の上
* 書き換えつつあったファイルの末尾（システムダウンの直前
数秒間に書き込んだ部分）が失われる => 上（仕方ないじゃん）
none
Yasushi Shinjo wrote:
> 新城＠筑波大学情報です。こんにちは。
> write back という用語がよく分からないのですが、これは、write
> しても、ディスク側のキャッシュに書くだけで、実際にはディスク
> には書かれないという意味ですか。
>
> 共有メモリの一貫性なら、write-through/copy-back というのはい
> いんだけど。ハードディスクなら、書き手は１つだから、back は
> ないんじゃないかと。
ディスクブロックの部分書き換えということもありますから、
(read-modify-write)べつに良いんじゃないでしょうか。日本語でも
「書き戻す」と言いますし。
とくにUNIXでは、ファイルシステムドライバは、あくまでも
バッファキャッシュやinodeキャッシュのみを相手にして
更新し、それをディスクに書き戻すのはファイルシステム
モジュールではなくて、バッファキャッシュモジュールや
inodeキャッシュモジュールの仕事(ふぁいるシステムモジュール
からはディスクI/Oはみえない)という構造になっているので、
ちょっと感覚が他のOSとは違うかも。
> aggregate の所がよくわからないんだけど、
> いくら溜めても、メモリが無くなれば最後は write するしかいな
> ので、平均的には特かもしれないけれど、極限状態だと危ないこと
> もあるんじゃないかなあ。
inodeやディレクトリなどは、1つのディスクブロックに複数の
エントリが含まれるので、複数の更新要求をバッファキャッシュ
で１回のディスクブロック更新にまとめることが出来ます。
積極的にこれをやるかどうかは性能に大きく影響を与えます。
また、一般にHDDは、ある程度の大きさの読み書きでないと性能が
出ません。4KBを16回書き込むよりは64KBを一気に書き込む方が
格段に早い。実際FFSでは、ファイルの内容(のある程度の大きさの
かたまり)をディスクの連続領域に割り当てるようにします。
キャッシュに溜める時間をむやみに延ばしても性能は頭打ちで
危険度は時間比例で高まるので、適切な時間待って書き込む
(dirtyblockを長時間持たない)のがバッファキャッシュの
チューニングのミソ。
たとえば、NEWS OSの非同期書き込みの初期には、
長く溜めすぎて、「しばらく高速に動くんだけど
バッファキャッシュを使い切ったところでHDDランプが
点灯しっぱなしになって30秒くらいがくっと体感性能が
落ちる」なんて不具合が出たりしていました。
結局、全dirty blockを一気にscheduleするというsyncの
仕組みを捨ててやっとまともになりましたっけ。
NAKAMURA Kazushi
In article <bgn3as$8kq$1...@newsserv.ics.es.osaka-u.ac.jp>
sai...@ist.osaka-u.ac.jp writes:
>* (OS 死亡がきっかけで) file system 全体が吹っ飛ぶ => 下の下
>* ディレクトリが吹っ飛んで lost+found 送り=> 下の下
>* ディレクトリの内容が狂って、名前と中身が食い違う> 下の下
>* write open してない個別ファイルが吹っ飛ぶ => 下の下
>* 書き換えつつあったファイルは吹っ飛ぶ => 下
>* 書き換えつつあったファイルの中身が失われる => 中
>* ディレクトリの内容が狂って、消した筈のファイルが残る> 中
>* ディレクトリの内容が狂って、消した筈のファイルの残骸が残る
> (が、fackで修正される)> 中の上
^^^^
fsckのtypoだと思うのですが、
* /etc/rcのfsck -pで修復しきれずに、manualyにfsck -yしたら、
/bin/shが吹っ飛んでboot -sも出来なくなる => fuck Uと叫びたくなる。
は経験しました。＃あっ、代わりに/bin/csh指定すれば良かったのかも。
>* 書き換えつつあったファイルの末尾（システムダウンの直前
> 数秒間に書き込んだ部分）が失われる => 上（仕方ないじゃん）
SAITOH akinori
NAKAMURA Kazushi wrote:
> * /etc/rcのfsck -pで修復しきれずに、manualyにfsck -yしたら、
> /bin/shが吹っ飛んでboot -sも出来なくなる => fuck Uと叫びたくなる。
> は経験しました。＃あっ、代わりに/bin/csh指定すれば良かったのかも。
kernelが飛ぶよりも、initやshが飛ぶ方が被害甚大ですね。
でも、/var,/tmp,/usrを別パーティションにしておけば
rootパーティションがfsck-pで手に負えないほど壊れることは
（まず）ないとおもいますが。あ、FFSやFFFSの場合ね。
V6時代とか、ext?fsのことはしらない。
Shinji KONO
In article <bgqmni$53j$1...@newsserv.ics.es.osaka-u.ac.jp>, SAITOH akinori <sai...@ist.osaka-u.ac.jp> writes
> kernelが飛ぶよりも、initやshが飛ぶ方が被害甚大ですね。
最初に/etc飛ばしたのは Vax 730 4.2BSD... D論直前で先輩にえらい
怒られた.... 次々に lost+found に落ちてくんですが、どうしようも
なかった... 4.3BSD に上げるときだったのでbackupはあったから、
気楽なものだったんですけどね。
> でも、/var,/tmp,/usrを別パーティションにしておけば
> rootパーティションがfsck-pで手に負えないほど壊れることは
> （まず）ないとおもいますが。あ、FFSやFFFSの場合ね。
最近だと、one partition って方が多いですよね。別にするに
しても、/home ぐらい。その方が、再インストールしやすいから。
IIJIMA Hiromitsu
> 最近だと、one partition って方が多いですよね。別にするに
> しても、/home ぐらい。その方が、再インストールしやすいから。
ん～、いろいろソフトをインストールしてると /usr が足りなくなるので、
あいている /home から融通したいってのはありますよ。
私ならたぶん /home も別パーティションにはしないですね。
うちの FreeBSD ですけど、Ports Collection の実体を /home/ports に置いて、
mount_null で /usr/ports にマウントしてみたり。
（これは鯖屋がセットアップ時に /home に容量を割きすぎているのがいけないん
だけど。）
========================================================================
飯嶋 浩光 / でるもんた・いいじま http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta mailto:delm...@ht.sakura.ne.jp
───【宣伝】─────────────────────────────
fj.os.ms-windows.server2003 または fj.os.ms-windows.server の新設の可否
を問う投票を実施中です。
fj.news.group.comp をご参照のうえ、ふるってご投票ください。
投票期限は 8/25(月)です。
────────────────────────────────────