/**ファイルシステム総合スレ その8**/

1 名前：login:Penguin mailto:sage [2007/09/26(水) 15:39:21 ID:VZk+Fjj0] 過去スレ 　01 pc.2ch.net/test/read.cgi/linux/1006743807/ 　02 pc5.2ch.net/test/read.cgi/linux/1063025258/ 　03 pc8.2ch.net/test/read.cgi/linux/1101495293/ 　04 pc8.2ch.net/test/read.cgi/linux/1136695633/ 　05 pc8.2ch.net/test/read.cgi/linux/1152348695/ 　06 pc11.2ch.net/test/read.cgi/linux/1173530292/ 147 名前：login:Penguin mailto:sage [2007/12/08(土) 01:25:50 ID:FeHiOV7B] >>146 inotify? 148 名前：login:Penguin mailto:sage [2007/12/08(土) 01:46:12 ID:FNgZ13Kb] >>146 ディレクトリのハードリンクは".."があるから構造的にムリだべ。 149 名前：login:Penguin mailto:sage [2007/12/08(土) 01:54:29 ID:sU/Rcdj4] >>147 inotifyってFSレベルで実装されてたのか。知らなかった。 inotifyを使ったバックアップソフトってもう登場してる？ ググっても見つからない・・・。 150 名前：login:Penguin mailto:sage [2007/12/08(土) 02:37:44 ID:YDy//UIh] ところで、NTFSが遅いのでLinux+sambaに置き換えようと思っているのだが、 ファイル数とパフォーマンスの比較ベンチみたいなデータ掲載してるサイト有りませんかね /home的なファイル群なのでパーテ多数作って細分化したら速度落ちないかなぁと期待してるんだけど。 xfsが巨大ファイルに強いってのは見たことあるんだけど、ファイル数での得手不得手ってどうなんでしょ。 151 名前：login:Penguin mailto:sage [2007/12/08(土) 02:54:59 ID:ELorHOyo] >>149 incron+今使ってるバックアップツール じゃだめなのか？ 152 名前：login:Penguin mailto:sage [2007/12/08(土) 03:57:20 ID:sU/Rcdj4] >>151 イベントが起こるごとにプロセス起動してたら、 せっかくの低い負荷が台無しになりそうな予感。 incron inotify.aiken.cz/ イベントを受け取って、指定されたファイルに イベント名とパスをひたすら出力するデーモンと、 そのファイルに書かれてるパスをバックアップするツールを 組み合わせるとかが妥当かな？ そうすれば好きなバックアップツールを使えるし、 負荷が低い深夜とかにバックアップさせることも出来るし。 153 名前：login:Penguin mailto:sage [2007/12/08(土) 04:29:16 ID:AOgHL0gM] てか、バックアップ対象のリストを作るだけならincron自体がいらないじゃん。 好きなバックアップツールだけをつかって負荷が低い深夜に(ry 154 名前：login:Penguin mailto:sage [2007/12/08(土) 04:35:29 ID:sU/Rcdj4] >>153 いやいや、それが最近の容量が大きいHDDだと、 一晩じゃバックアップできないんだよね。 手持ちサーバだと、差分バックアップしても10時間ほどかかってる。 そこでイベント処理で素早くできないかなと。 155 名前：login:Penguin mailto:sage [2007/12/08(土) 04:50:40 ID:AOgHL0gM] >>154 ファイルシステムレベルでのスナップショットがいるんじゃない? とふってみよう。 156 名前：login:Penguin mailto:sage [2007/12/08(土) 04:56:58 ID:sU/Rcdj4] >>155 確かにスナップショットは欲しいけど、 本稼働サーバでXFSを試すほどではないかなー。 157 名前：login:Penguin mailto:sage [2007/12/08(土) 06:02:13 ID:AOgHL0gM] >>156 更新をIN_ONESHOTで監視してイベントを受け取ったらデイリーバックアップ ってことにすればいいんじゃねぇと思ったけど、肝心のinotify(7)って、 監視イベントを踏んだ方はイベントを受け取るプロセスをただ起こすだけで、 処理をじゃんじゃか続行してかねーか? 158 名前：login:Penguin mailto:sage [2007/12/08(土) 11:54:13 ID:7rFxjzQG] >>149 バックアップとはちと違うかもしれんがこんなのか freshmeat.net/projects/lsycnd/ 159 名前：login:Penguin mailto:sage [2007/12/08(土) 13:58:48 ID:fXv3+El5] inofityって監視したい対象ごとにinotify fdに追加していかなきゃいかんから システム全体の全ファイルをモニタするのは無理。 欲しいのはVFS hookなんだけど、LSMとかkprobesでモニタするような処理を 挿入できるのかなぁ。 160 名前：login:Penguin mailto:sage [2007/12/08(土) 17:21:09 ID:9+lQmPMD] >>154 それrsyncで普通にバックアップした方が結局速くなったりしない？ 161 名前：login:Penguin mailto:sage [2007/12/08(土) 18:03:30 ID:sU/Rcdj4] >>158 おっ、やっぱりあったね。 >>159 まじで・・・。 トップディレクトリだけじゃダメなんだ？ >>160 今rsync使って10時間。 rsync 3.0でメモリ使用量が激減するらしいので、 そうなれば少しは早くなるかなとは思うけど。 162 名前：login:Penguin mailto:sage [2007/12/08(土) 19:42:14 ID:AOgHL0gM] >>159 mmap(2)してるやつまで考えると頭が痛くなりそうな気がする・・・ 163 名前：login:Penguin mailto:sage [2007/12/10(月) 09:05:05 ID:1o7EIMpK] >>146 backup/restoreしたらリンクが切れそうだ 164 名前：login:Penguin mailto:sage [2007/12/16(日) 22:42:42 ID:kEiA0RYk] 同時アクセスに強いFSって今だとどれ？ 165 名前：login:Penguin mailto:sage [2007/12/17(月) 00:22:30 ID:HS8oigxL] >>164 read に関してページキャッシュに乗ってればどれでも一緒じゃないか？ とコードも見ずに言ってみよう。 166 名前：login:Penguin mailto:sage [2007/12/17(月) 01:55:43 ID:RktuIZ7Z] ヘッドシークが短くなるよう設計してる(らしい)ReiserFS 167 名前：login:Penguin mailto:sage [2007/12/17(月) 05:01:49 ID:sg1FvI6J] その手の話は下でLVMやmdなどが動いていたら、fsレベルで何をやってもほとんど無意味じゃない? fsレベルで下位のデバイスを直接面倒見るようにしないと、あまり高級なことはできなんだよなぁ。 168 名前：login:Penguin mailto:sage [2007/12/17(月) 10:14:55 ID:xMRdJbZY] それってI/O schedulerの仕事な気がする ReiserFSはnoopと組み合わせたときに最高のパフォーマンスになるのだろうか 169 名前：login:Penguin mailto:sage [2007/12/18(火) 01:29:57 ID:+yZejH3O] もし FSに与えられたボリュームの先頭と末尾にFAT的なものを設置して頻繁にsyncをかける、 などというFSがあったらやはり遅いのでは？ よくある環境で遅くなりにくいFS実装というのはありだろう。実際にどれがどうなのかは知らんけど。 同時アクセスつーても大雑把すぎるが、エントリのリストアップが高速なFSはWin向けによさそうかな 170 名前：login:Penguin mailto:sage [2007/12/18(火) 04:18:07 ID:6DnGK8YD] じゃあtmpfsが最強ってことでおｋ？ 171 名前：login:Penguin mailto:sage [2007/12/18(火) 09:57:01 ID:stAupCCv] 次点はReiser4な 172 名前：login:Penguin mailto:sage [2007/12/19(水) 03:03:55 ID:ICj0cKZP] Resier4そんな速いのかw ext2で中途半端にキャッシュに乗った状態はすこぶる遅いと表明しておこう ext3は挙動がよくわからない 173 名前：login:Penguin mailto:sage [2007/12/19(水) 09:37:18 ID:FtoZ4/4Y] >>172 >ext2で中途半端にキャッシュに乗った状態はすこぶる遅いと表明しておこう 何今更ネタを披露してんだ？ 174 名前：login:Penguin mailto:sage [2007/12/20(木) 06:22:34 ID:vEhWN4uA] NTFSはもっと遅い 175 名前：login:Penguin [2007/12/30(日) 13:51:28 ID:1u1is7/Z] ちょっと前にイベント処理の話し出てたけど、 Mac OS Xは↓こうなってるらしい。翻訳もしてくれた人がいた。 arstechnica.com/reviews/os/mac-os-x-10-5.ars/7 pc11.2ch.net/test/read.cgi/mac/1194073058/54-63 なかなかおもしろいね。 Be OSの方もどうなってるのか気になるなー。 176 名前：login:Penguin mailto:sage [2007/12/31(月) 01:38:48 ID:u9rDnk0D] ext3の500GBのHDDに500M〜2GBぐらいのTV録画のmpegファイルを適当に放り込んでいたら一杯になったので、 もう一個SATA|IDE-HDDを買ってきてUSBでつないでバックアップつーか要保存のだけ そっちに整理することにしたのだが、ファイルシステムは何がいいでしょうね? 保存用なので、HDDの利用効率(ext3はちょっと目減り激しい気がす)と壊れにくいのがいいのだけど、 場合によってはUSBで直付けしてWindowsでも見れるntfsもありかなと思っているんだけど。 177 名前：login:Penguin mailto:sage [2007/12/31(月) 02:21:15 ID:bruoMmTv] btrfsで。 178 名前：login:Penguin mailto:sage [2007/12/31(月) 02:31:26 ID:u9rDnk0D] >>177 ありがとう。調べてみます。 179 名前：login:Penguin mailto:sage [2007/12/31(月) 02:49:08 ID:+0ONQ7NM] btrfsはまだアルファ版では？ 180 名前：login:Penguin [2008/01/12(土) 02:03:46 ID:jzLk1uOI] >>175 Appleも日本語リファレンス出したよ。 ファイルシステムイベント プログラミングガイド developer.apple.com/jp/DOCUMENTATION/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/chapter_2_section_1.html 181 名前：login:Penguin mailto:sage [2008/01/12(土) 02:29:53 ID:Bx7hU4VM] 板違いの話でなんでざーとらしくageちゃうんだろ・・・。 いや、触ったら連中の思うツボ。ここは触っちゃいけないんだったな。くわばら、くわばら。 182 名前：login:Penguin [2008/01/12(土) 05:25:06 ID:MhamVZBR] 住人気取りきめぇ 183 名前：login:Penguin mailto:sage [2008/01/12(土) 05:29:58 ID:jzLk1uOI] >>182 住人だし。 イベント処理を使ったバックアップが出ないかなーと思ってるから、 参考になるかなと思って貼っただけ。 184 名前：login:Penguin mailto:sage [2008/01/12(土) 05:38:03 ID:SErII+Xc] 気にも留められずに無視されるよりは、たとえ嫌われてでも意識してもらえる方がマシ…とかね たとえウザがられようともMacやAppleという単語を目に触れさせるようにして、 1000人に一人でも10万人に一人でもいいから 「でもちょっと調べてみるか」くらいのアホが出て来ることを期待してるんだよ 自分たちの何十倍も巨大で、そしてその殆どが自分たちに対して興味すら抱いていない場合に 最も有効な戦略は、まずウザがられて叩かせることなんだ ほんの10年前、2chができる前に、韓国や北朝鮮や、在日の話なんて誰も知らなかっただろう？ 今では2chに来る人の間では、ほとんど常識になっているよね。 必死に彼らを叩く嫌韓厨たちは、連日「韓国」」「朝鮮」「在日」といった単語を 宣伝して回っていたというわけだ。憎悪に駆られて毎日膨大な時間を、韓国ニュースとかを漁ってね。 Appleも、同じ事をやり始めた。いくらメリットを説明しても、メッセージが届かなければ宣伝にならない。 まずはちょっとひと揉みしてアンチを生み、彼らに宣伝を手伝ってもらおう。…今は、そういう段階なんだよね 185 名前：login:Penguin mailto:sage >>184長文乙 [2008/01/12(土) 06:01:06 ID:jzLk1uOI] しかしこれだけストレージが大容量化されてくると、バックアップが大変。 HDDの障害はRAID構成で対処できるけど、 RAIDコントローラーの障害、ファイルシステムの破損は、 結局外部メディアにバックアップしておくしかない。 もし落雷や火事にまで対応するのなら、ネット経由でのバックアップが必要。 しかし常にLoadAverageが高いサーバだと、 バックアップのために割けるCPUリソースがない。 そこで、イベント処理型のバックアップシステムが必要とされてると思うんだけど。 とくにSANなどの外部共有ストレージが使えない低コストが求められる環境だとなおさら。 そういう需要って少ない？ 186 名前：login:Penguin mailto:sage [2008/01/12(土) 06:37:11 ID:bmbAU9+b] スレ違いだが…… >>184 それで嫌韓連中を増やしたことが韓国のメリットになったのか？ アップルもしくはその支持者の戦略だとするなら、まずそこを 検討しているはず、と思うのだが。 187 名前：login:Penguin mailto:sage [2008/01/12(土) 06:57:51 ID:SErII+Xc] >それで嫌韓連中を増やしたことが韓国のメリットになったのか？ 韓流ブームはTVと週刊誌で成立したものだと思ってるクチ？ その下地づくりが何時から始まったのか、調べてごらんよ 188 名前：login:Penguin mailto:sage [2008/01/12(土) 07:07:04 ID:bmbAU9+b] >>187 なにを示唆したいのか、さっぱり分からん。 てか、「ほのめかし」に終始して会話する気ないでしょ。 189 名前：login:Penguin mailto:sage [2008/01/12(土) 07:22:17 ID:SErII+Xc] 理解する気がないくせに「会話する気がない」って何様 190 名前：login:Penguin mailto:sage [2008/01/12(土) 10:50:20 ID:4BgmnGqv] >>185 真にバックアップの必要なデータって極わずか。 それらが大量にあるというなら、それなりの コストを払ってSAN上で２重化すれば。 つかCPUマシンとI/Oマシンくらい別にすれば。 191 名前：login:Penguin mailto:sage [2008/01/12(土) 11:09:04 ID:IDm5jJbB] >つかCPUマシンとI/Oマシンくらい別にすれば。 なんだその表現ｗｗｗ 192 名前：login:Penguin mailto:sage [2008/01/12(土) 11:27:17 ID:jzLk1uOI] >>190 SANが導入できる予算があれば苦労しないわけで。 しかしSANってかなりファイルアクセスコスト高いから、 大量の小さいファイル（HTMLとか）で 500GBとか占めてるサーバの差分バックアップ取ろうとしたら、 かなり時間掛かるんじゃないだろうか。 ブロックコピーだったら問題ないけど。 193 名前：192 mailto:sage [2008/01/12(土) 11:29:24 ID:jzLk1uOI] SANはSANでも共有ファイルシステムを使った場合の話しね。 194 名前：login:Penguin mailto:sage [2008/01/12(土) 11:52:55 ID:4BgmnGqv] >>192 >大量の小さいファイル（HTMLとか）で >500GBとか占めてるサーバの差分バックアップ取ろうとしたら それらが本当にバックアップ対象なの？ 差分とる必要があるなら、差分がとりやすいような構成に するんじゃないのか。何も考えずに/varに500GBとか やってるんすかね。 195 名前：login:Penguin mailto:sage [2008/01/12(土) 11:55:47 ID:yT37g0aU] >>185 そんなだらだらとしたバックアップが実際に役に立つと思いますか？ データの一貫性を保つためには、きちんと決められた時点のデータがすべて揃わないと何の意味も無いんですよ。 あなたみたいな、ハードウェア的な要件だけでしか物事を考えられないSEは邪魔なだけですよ。 196 名前：login:Penguin mailto:sage [2008/01/12(土) 12:26:21 ID:jzLk1uOI] >>194 HTMLの場合もあれば、2chのdatファイルのようなこともあれば、 Maildirのメールファイルのこともある。 HTMLやMaildirの場合はディレクトリ構成とかをこっちの自由にはしにくいから、 全体で差分バックアップを取る必要がある。 >>195 DBのバックアップじゃないから、OK。 HTMLの場合なんかだと、スナップショットを取る必要すらない。 決めつけの頭固いSE乙。 197 名前：login:Penguin mailto:sage [2008/01/12(土) 12:30:53 ID:iYG31qhb] Appleのドキュメント見に行ったけど、バックアップに使うというのは、 イベントによってファイルシステムのある瞬間の状態をとれるということだよね。 スナップショットをとってのバックアップだったらLVMとかでLinuxで既にやっているし？ あまりLinuxで似たような実装するとか(効果や労力の点で)考える必要ないんじゃない？ と思ったけど、そういうこととは違うの？ 198 名前：login:Penguin mailto:sage [2008/01/12(土) 12:43:43 ID:jzLk1uOI] >>197 いや、違う。 例えば100KBのファイルが5000000個あるボリュームがあって、 それの差分バックアップを取りたい場合、前回との差を調べるだけで、 １〜５時間ぐらい（バックアップ先やLAによって異なる）かかる。 でも実際にはほとんど更新されてなかったりして、 ファイルコピー自体は10分ぐらいで終わってしまったりする。 そこでどのファイルが更新されたのかをイベント処理によって検知して、 その更新されたファイルリストを作っておき、 そのファイルだけをコピーするようにすれば、 差分バックアップがあっという間に出来てしまう。 これなら１時間おきに差分バックアップを取ることも可能。 ってことをやりたい。 199 名前：login:Penguin mailto:sage [2008/01/12(土) 13:07:29 ID:iYG31qhb] ionotify APIを使えばできるようになるのかなあ www.linux.or.jp/JM/html/LDP_man-pages/man7/inotify.7.html うーん、これを利用するプログラムなら、もうあった気がする。 というかそのプログラムの説明でこのAPIを知った筈なんだが。 200 名前：login:Penguin mailto:sage [2008/01/12(土) 17:24:53 ID:Y+I93RRs] lsyncd www.pri.univie.ac.at/index.php?c=show&CEWebS_what=Lsyncd これか？ 201 名前：login:Penguin mailto:sage [2008/01/12(土) 17:37:47 ID:zybZJIGE] で、ループしてinotifyは監視できるノード数に限界があって・・・、で戻る。 inotifyで/以下監視しようとするとさくっと死亡します。 ただし、/home以下ならユーザー数や利用のされ方しだいでは可能。 現実的な策としてAppleの実装は参考になるよ。 もっとも根底からinotifyとは違う方式なので、単にログサーバが 別途あればいけるというようなことにはならない＞Linux 202 名前：login:Penguin mailto:sage [2008/01/12(土) 17:56:05 ID:Bx7hU4VM] >>198 > HDDの障害はRAID構成で対処できるけど、 > RAIDコントローラーの障害、ファイルシステムの破損は、 > 結局外部メディアにバックアップしておくしかない。 > もし落雷や火事にまで対応するのなら、ネット経由でのバックアップが必要。 よくわからんが、その「どのファイルいぢったかイベントドリブンでメモしときましょう型」 バックアップってさ、結局そのメモスレッドが走ってるCPUマシンが障害起こしたら おしまいじゃねーの? バージョン(世代)管理型のバックアップでもないようだし RAIDコントローラーの障害を心配して、RAIDにしない理由がいまいちわからん。 RAIDコントローラーを一枚(or一台)余計に 買って使わないで保存しとけば、RAIDでOKじゃね? 203 名前：login:Penguin mailto:sage [2008/01/12(土) 20:48:27 ID:1iC8xxCD] >>202 ID:jzLk1uOI はRAIDを使わないとは言ってないのでは？ RAIDがあってもバックアップは大切。 そのバックアップを早くしたいって話なんじゃないの？ 204 名前：login:Penguin mailto:sage [2008/01/12(土) 22:13:37 ID:jzLk1uOI] >>201 同意。 >>202 203の通り。 >>203 代わりのレスあり。 205 名前：login:Penguin mailto:sage [2008/01/12(土) 22:16:35 ID:4BgmnGqv] >>204 金も知恵も使いたくないなら RAID１やってバックアップとるとき抜いて、 別マシンで差分とればいいんじゃね？ 206 名前：login:Penguin mailto:sage [2008/01/12(土) 22:23:07 ID:jzLk1uOI] >>205 RAID1の片方のHDD抜いたら、 ホットスペアディスクに転送始まって、 終わるまで重くてしょうがないよ。 それにわざわざデータセンター行かないとできないし。 207 名前：login:Penguin mailto:sage [2008/01/12(土) 23:01:22 ID:Bx7hU4VM] >>204 RAID5/6でもダメ? バックアップ取りたいってのは分かる気がするけど んーとさ、これってファイルシステムレベルで やる話なのかな?って思った。 アプリケーションレベルで保存先二つにするとか、 ユーザのログアウト時にユーザの書き込み範囲だけ バックアップ同期するとかそんなんでもよさげな気がす。 208 名前：login:Penguin mailto:sage [2008/01/12(土) 23:28:26 ID:gMk/W/4K] >>207 というかブロックレベルでやればいいよな、と思った。なに？EMC高い？AX4なら100万以下だぜ 209 名前：login:Penguin mailto:sage [2008/01/12(土) 23:43:07 ID:Bx7hU4VM] >>208　そりゃそれなら文句ないだろうけど。 ここの話で、確かにもう少しそういうものの小規模、低コストなものは需要があるのかもしれんね、とおもた。 210 名前：login:Penguin mailto:sage [2008/01/12(土) 23:58:53 ID:D/8nBsgE] クラスターファイルシステムもここでいいんかな？ iSCSI+ocfs2でファイル共有したいんだが、centos5.1とubuntu7.10だと同時にマウントできない centos5.1同士、ubuntu7.10同士は問題ない centos5.1がocfs2 1.2.7-1、ubuntu7.10がocfs2 1.24 バージョン違うと共有できんのかな？ gfs2はバージョン違うとダメだったりします？ ocfs2とgfs2のそれぞれの利点がさっぱり分かりません・・・ 211 名前：login:Penguin mailto:sage [2008/01/13(日) 10:03:01 ID:Nollm+Al] >>210 基本的に、クラスタで両方からいっぺんにアクセスされる可能性があるものの場合は バージョンをあわせなきゃダメだろ。バージョンが違うと言うことは機能に違いが あるということなのだから。 212 名前：login:Penguin mailto:sage [2008/01/13(日) 13:45:13 ID:uE2Jrzt9] >>204 nzfug.nz.freebsd.org/nzfug/AndrewThompson/ZfsForReplication FreeBSDの話だけど。 ZFSでsnapshot作って、前回のsnapshotとのバイナリ差分をリモートに送信・同期させる方法。 213 名前：login:Penguin mailto:sage [2008/01/13(日) 14:04:33 ID:weLbJnIm] そういえばUNIXマガジン買ったやつはいないのか。 214 名前：login:Penguin mailto:sage [2008/01/13(日) 14:42:06 ID:T1kxn9Tz] >>208 そのAXなんちゃらEMかんちゃらも高いからなあ。 なら自分は手順覚えれば無料のを使った方がいいや。 215 名前：204 mailto:sage [2008/01/13(日) 22:38:13 ID:PiB7mojI] >>207 > アプリケーションレベルで保存先二つにするとか、 Webアプリが出力したデータをバックアップするときは、この方法使うこと多いね。 けど、FTPでアップされたファイルとかだと デーモンをいじらないと出来ないから、キツいねー。 >>212 おっ、これ理想的かも。 216 名前：login:Penguin mailto:sage [2008/01/14(月) 00:20:29 ID:qmocvwzd] NetBSD上でだけど、ファイルの書き込みや移動、削除が発生すると ファイルパスを通知するファイルシステムを昔作ったよ。 理由はmknmzが毎度毎度ディレクトリを全部スキャンして遅かった からなんだけど…。 既存のファイルシステム(overlay filesystem)のコードを流用したから、 結構簡単に作れたよ。 Linuxでも検討してみたけど、ファイルシステムの設計がスタッカブル じゃないんで面倒臭くなってやめちゃったなあ。 今ならFUSEとunionfsを駆使すれば、同じようなことでできるんじゃないかな？ 217 名前：login:Penguin mailto:sage [2008/01/14(月) 00:37:09 ID:6n5zEajJ] aufs使えばできそうだな。 218 名前：login:Penguin mailto:sage [2008/01/14(月) 02:19:06 ID:qPxdU3yy] vfsで実装 219 名前：210 mailto:sage [2008/01/15(火) 02:26:55 ID:BF3bHG9k] >>211 やっぱそうですよね、合わせないとダメですよね・・・ ubuntuの方を1.27にしてみます ocfs2とgfs2の違いは相変わらずよく分からん、ocfs2の方が設定簡単そうぐらいしか 220 名前：login:Penguin mailto:sage [2008/01/15(火) 03:29:14 ID:Ar++HS05] SDカードのFATエントリなんか他のエリアと比べて 何倍も書き換えられると思うんだけど フラッシュメモリの使い方として問題ないの？ 221 名前：login:Penguin mailto:sage [2008/01/15(火) 03:30:48 ID:jvp0V+W6] 今はフラッシュメモリ側で散らす機能があるでしょ。 222 名前：login:Penguin mailto:sage [2008/01/15(火) 03:40:12 ID:Ar++HS05] ほー、なるほど賢いね。 カードに直接そういう機構がそなわってるってこと？ それともカードを扱う使用機器のドライバ側ってこと？ 223 名前：login:Penguin mailto:sage [2008/01/15(火) 03:42:21 ID:edpzbljx] カード側で持ってるよ。アルゴリズムは各社の極秘中の極秘だそうだ まあカードの書き換え速度や寿命に如実に影響する肝の部分だしな 224 名前：login:Penguin mailto:sage [2008/01/15(火) 03:54:19 ID:Ar++HS05] なるほどありがとう。 しかしそうするとメモリーカード上のフラグメンテーションって 純粋に仮想的なもので実測には影響しないのかな。 225 名前：login:Penguin mailto:sage [2008/01/15(火) 03:57:55 ID:edpzbljx] フラッシュメモリはSDRAMみたいにバーストリードで速度が上がるとかいう要素は無いだろう ランダムリードと言っても元々数KB〜数十KB単位のセル単位で読み書きだし そのセルが物理的に離れた箇所にあったとしても、スピンドル回してヘッドがギコギコ動く訳じゃないから どれだけアクセス時間がかかるかとかはほとんど誤差の領域じゃないかねえ まあ俺も素人だから正味のところはわからんが それよりもコントロールロジックの処理速度の方が遥かに影響が大きそうだ 226 名前：login:Penguin mailto:sage [2008/01/15(火) 04:23:10 ID:RzvkwwJj] 知ってる方がいたら教えてほしいのですが、ext3のdata=journalのモードってのは 本当にフルデータジャーナリングなのでしょうか。メタデータだけじゃなくて、データ の変更についてもジャーナルログに書き出してるんでしょうか。 大抵の文書には、 「フルデータジャーナリングじゃ」だから「2度データが書き出される」と書いてあるのですが、 @ITの記事によると「journalモードではディスクへの書き込みが完了したことを確認してから ジャーナリングの記録を行う」とありまして、同期書き込み＋メタデータジャーナリングのよう な解説をしてあります。これだとデータの書き出しは1度だけです。 www.atmarkit.co.jp/flinux/rensai/fs04/fs04b.html 詳しく解説してあるので、@ITの方が正しいような感じがするのですが、どんなもんでしょう。 それからもう一つ疑問なのですが、フルデータジャーナリング使うぐらいなら 同期マウントした方が良い気がするのですが間違ってますか？ （同期マウントでもメタデータの更新中に停電したらアウト…なのかな） アホな質問ですいません 227 名前：login:Penguin mailto:sage [2008/01/23(水) 01:52:59 ID:N7D3q8Og] ここで言う同期マウントって例えば？ 228 名前：login:Penguin mailto:sage [2008/01/23(水) 13:49:47 ID:1HOl8oN3] -o sync, dirsync 229 名前：login:Penguin mailto:sage [2008/01/23(水) 14:27:45 ID:l6jXIqfH] 同期モードでmountしている状態でもクラッシュしたらfsckが必要ですし 実現できる機能が違いますよね 230 名前：login:Penguin mailto:sage [2008/01/25(金) 05:13:31 ID:V+xKWgCR] そもそも同期モードで書いてる途中で落ちたとして、 どこまで何を書いたかは誰が覚えてるんだろうねぇ？ 231 名前：login:Penguin mailto:sage [2008/01/25(金) 19:51:15 ID:OAhQQFKa] 誰も覚えていない。 書き込みそのものがなかったものになるだけ。 232 名前：login:Penguin mailto:sage [2008/01/26(土) 07:10:51 ID:nkamkNao] それはジャーナル有る場合だろ 233 名前：login:Penguin mailto:sage [2008/01/26(土) 07:50:09 ID:8OpwyOTH] はあ？ 234 名前：login:Penguin mailto:sage [2008/01/26(土) 14:24:53 ID:nFnPAV3G] 同期・非同期とトランザクションの区別はつけようぜ。 235 名前：login:Penguin mailto:sage [2008/01/26(土) 15:24:51 ID:Pvih2f3X] >>232 fsckでなかったものにされるんじゃね？ ジャーナルなんて関係ないでしょ。 236 名前：login:Penguin mailto:sage [2008/01/26(土) 15:53:50 ID:8QyNar63] >>235 fsckすると残りのジャーナルを適用することもある。 どっちが整合性を保ちつつデータを保全できるかによるようだ。 237 名前：login:Penguin mailto:sage [2008/01/26(土) 17:14:55 ID:X0RlC9mR] ちょっとまて >>226の >フルデータジャーナリング使うぐらいなら同期マウントした方が良い かどうかだろ ジャーナリング無しで同期書き込みしたらfsckでロールバックかかるってこと？？ 238 名前：login:Penguin mailto:sage [2008/01/26(土) 17:25:57 ID:IqVOKU/f] ちゃんと流れ読めよ 239 名前：login:Penguin mailto:sage [2008/01/26(土) 19:00:37 ID:Pvih2f3X] >>236 なんでそうなるのか、それがわからん。 同期の場合は、sync（）にしろwrite（）にしろ、書き込みがすべて終わるまで戻ってこないんでしょ？ 対象がジャーナルFSであっても。 >>237 fsckで行う作業をロールバックというな。 240 名前：login:Penguin mailto:sage [2008/01/26(土) 21:51:13 ID:X0RlC9mR] 状況がよく分からんのだが、ファイルの内容書き換え中に落ちたとして、 fsckでどうやってロールバックされるわけ？ >>230な状況になるんじゃないのか 241 名前：login:Penguin mailto:sage [2008/01/27(日) 01:29:39 ID:LrB7nbuV] RDBMSの場合は、SQLレベルでの論理的な操作すべてが記録されているから、 直前のバックアップデータに対してログをリプレイすることで、完全復旧ができるというわけだが、 ファイルシステムに当てはめて考えれば、バイトレベルの操作すべてに対してログが採られていなければ、データの中身までは保障できないということになる。 現実的には、そんなことしてたらログの量がとてつもなくなるから、到底無理な話。 ジャーナルFSが復旧処理でやっていることは、通常のfsckがすべてのファイルに対して実行する検査を ログをなめることで省略しているにすぎない。 当然、正常に閉じていないファイルは、問答無用でlost+found逝きとなる。 これをロールバック/フォワードなどという言うには違和感あるでしょ？ 242 名前：login:Penguin mailto:sage [2008/01/27(日) 03:02:00 ID:i1WeOFxf] >>241 データについてもする場合はopen以後のwriteは別領域に書いて、 適当なタイミングでFS構造からの参照を付け替えればいいだけ。 この場合、write中にクラッシュした後の復旧でロールバックする。 ただし XFS とかの実装だとcreat自体はコミット済みだから ０バイトファイルが残ってくれたりとある意味困った挙動になったり。 さらに進んでNTFSとかreiser4ではアプリ側からトランザクション性を 制御した書き込みができる（た？）はずだけど、どういう形なんだっけ？ あとfsckがやってるのは正常に閉じられなかったファイルではなく、 参照があるのに参照先がないとか、参照がないのに実体があるとかの FS構造としての不整合状態をブロックをなめて発見したものを lost+foundに集めたりクリアしたりしてるだけで、閉じられなかった ファイルを救ってるわけではない。 243 名前：login:Penguin mailto:sage [2008/02/02(土) 17:24:24 ID:Sk+gOLYe] どこのスレが該当するかわからんがとりあえずここに。 mdadmでraid1構築、ocfs2にフォーマットしてマウントは問題ないんだが、 raid0とraid10で同じ事をやると失敗する。 (ひとまずローカルディスクで実験してます。最終的にはiSCSIを複数使ってやる予定) 以下マウント時のエラー ocfs2_hb_ctl: I/O error on channel while starting heartbeart mount.ocfs2: Error when attempting to run /sbin/ocfs2_hb_ctl: "Operation not permitted" /etc/init.d/o2cb statusすると確かにハートビートが動いてない。 んで手動でocfs2_hb_ctl -S -d /dev/md7(作ったRAIDデバイスがmd7)実行するも ocfs2_hb_ctl: I/O error on channel while starting heartbeart でダメ。 これはocfs2の仕様なんですかね？GFS2だとなんとかなる？ clvmで-iと-mのが可能性あったりするのかなあ、もうわけわからん 244 名前：login:Penguin [2008/02/06(水) 21:12:32 ID:xB+Vp2Cl] トーバルズ：OS XはVistaよりマシ、でもファイルシステムはゴミ japanese.engadget.com/2008/02/05/linus-os-x-vista/ ktkr 245 名前：login:Penguin mailto:sage [2008/02/06(水) 21:24:53 ID:xsQFoZY7] 誰か言ってやってくれ LinuxはServer2008よりマシ、でもファイルシステムはゴミ 246 名前：login:Penguin mailto:sage [2008/02/06(水) 21:35:04 ID:CEBTMN4n] >>245 いやそれは逆だろ。 ファイルシステムはマシだが・・・。 247 名前：login:Penguin mailto:sage [2008/02/06(水) 21:43:01 ID:bycraF9D] NTFSってどうなん？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef