- 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/
- 136 名前：三文字路線で mailto:sage [2007/11/24(土) 21:38:39 ID:BiG3ryPJ]
- おっ、ID が ビッグ3 だ…
というわけで勝手に ZFS XFS JFS を ビッグ3 と決めますた
- 137 名前：login:Penguin mailto:sage [2007/11/24(土) 21:44:18 ID:lC7phVQh]
- >>117
ocfs2とかどないなのか気になる。
というか次世代となるとクラスタFSになるんじゃない？
速度や信頼性を追求する場面でextとかxfsとかいう話は出てこなくなるのかも
- 138 名前：login:Penguin mailto:sage [2007/11/24(土) 21:51:40 ID:8qHXSCfW]
- zfsもクラスタ対応になるんじゃなかったっけ？
- 139 名前：login:Penguin mailto:sage [2007/11/24(土) 22:01:51 ID:sauQFbv3]
- クラスタ対応とかは興味ないというかいらないなぁ、クライアントじゃぁ。
- 140 名前：login:Penguin mailto:sage [2007/11/29(木) 19:45:24 ID:rD7JhOhk]
- 次世代ファイルシステムの行方
japan.internet.com/column/webtech/20071129/6.html
- 141 名前：login:Penguin mailto:sage [2007/11/30(金) 09:37:54 ID:rV4snyMU]
- 特に何の意味もない記事だなあ。
- 142 名前：login:Penguin mailto:sage [2007/11/30(金) 10:42:43 ID:mleGbSeF]
- っていうか「日記はチ(ry」
- 143 名前：login:Penguin mailto:sage [2007/11/30(金) 21:26:49 ID:pAVg9f1O]
- Linux ファイルシステムの徹底調査
www.ibm.com/developerworks/jp/linux/library/l-linux-filesystem/
- 144 名前：login:Penguin mailto:sage [2007/11/30(金) 21:30:53 ID:deZGR6be]
- ＞以上が、20,000 フィートの上空から眺めた VFS とファイルシステム・コンポーネントの全体像です。
いいね、こういうのは。
- 145 名前：login:Penguin mailto:sage [2007/12/01(土) 22:07:33 ID:g+5VeIb9]
- お前もカーネルと一緒に静止軌道衛星で上空に浮かんでろ！
て、思う。
- 146 名前：login:Penguin [2007/12/08(土) 01:20:52 ID:sU/Rcdj4]
- Linuxって、FS層にイベント処理組み込む予定ないんだろうか？
実装されたら、サーバ間同期とか、リアルタイムバックアップを、
低い負荷で実現できそうなのに。
あとはパーティションを超えてのハードリンクと、
ディレクトリのハードリンクが実装されないかなー。
- 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すると残りのジャーナルを適用することもある。
どっちが整合性を保ちつつデータを保全できるかによるようだ。
|
 |
