[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 04/23 11:50 / Filesize : 225 KB / Number-of Response : 987
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

/**ファイルシステム総合スレ その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/


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上で2重化すれば。

つかCPUマシンとI/Oマシンくらい別にすれば。


191 名前:login:Penguin mailto:sage [2008/01/12(土) 11:09:04 ID:IDm5jJbB]
>つかCPUマシンとI/Oマシンくらい別にすれば。

なんだその表現www

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個あるボリュームがあって、
それの差分バックアップを取りたい場合、前回との差を調べるだけで、
1〜5時間ぐらい(バックアップ先やLAによって異なる)かかる。
でも実際にはほとんど更新されてなかったりして、
ファイルコピー自体は10分ぐらいで終わってしまったりする。

そこでどのファイルが更新されたのかをイベント処理によって検知して、
その更新されたファイルリストを作っておき、
そのファイルだけをコピーするようにすれば、
差分バックアップがあっという間に出来てしまう。
これなら1時間おきに差分バックアップを取ることも可能。

ってことをやりたい。

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
金も知恵も使いたくないなら
RAID1やってバックアップとるとき抜いて、
別マシンで差分とればいいんじゃね?

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自体はコミット済みだから
0バイトファイルが残ってくれたりとある意味困った挙動になったり。

さらに進んで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ってどうなん?

248 名前:login:Penguin mailto:sage [2008/02/06(水) 21:45:17 ID:AbBwRF41]
ゴミ

249 名前:login:Penguin mailto:sage [2008/02/06(水) 21:45:58 ID:kmV4D3eE]
速度的に光るものはないが、耐久力はゾンビ級。
ext3なんかよりよっぽど優れたfsだと思うんだけどな…

250 名前:login:Penguin mailto:sage [2008/02/06(水) 21:59:15 ID:MW2Uiq4L]
>>249 それ賛同


251 名前:login:Penguin mailto:sage [2008/02/07(木) 00:55:39 ID:Jh0j2rM7]
リーナスってバカだな


252 名前:login:Penguin mailto:sage [2008/02/07(木) 03:33:18 ID:UdsqPHwZ]
ntfsでファイルがぶっ飛んで破片も出てこないのはプログラムが悪いの?

253 名前:login:Penguin mailto:sage [2008/02/07(木) 10:56:01 ID:NVBqFf6j]
俺なんかはntfsよりreiser・・・じゃなかった、xfsで何事も無かったように再起動できたことに驚愕したものだが。
ntfsだとどっか壊れるよなーという落とし方をしてしまった時のことだ。

まぁxfsはfsckしないからというのもあるだろうが。



254 名前:login:Penguin mailto:sage [2008/02/07(木) 11:16:04 ID:JbuBRM/5]
>>253
どこかに0バイトのファイルが転がってるかもよ。

255 名前:login:Penguin mailto:sage [2008/02/07(木) 17:47:13 ID:nagQT8db]
ちなみにどういう落とし方したの?

256 名前:login:Penguin mailto:sage [2008/02/07(木) 18:16:17 ID:lsDyIYji]
酒を飲みつつ恋愛論を語った

257 名前:login:Penguin mailto:sage [2008/02/07(木) 18:26:42 ID:MhI2GJBO]
たしかにntfsだとぶっ壊れそうだ。
あとできちんとf*ckしとけよ。

258 名前:login:Penguin mailto:sage [2008/02/08(金) 02:06:16 ID:5Qp7toYJ]
いったいなんのスレだよw


>>253
xfsはマウント時にfsckするんじゃなかったっけ?

259 名前:login:Penguin mailto:sage [2008/02/08(金) 02:20:17 ID:SRnPVqDy]
>>258
昔のxfs_fsck.c

int
main(int argc, char **argv)
{
return 0;
}

今はshell scriptになったな。

260 名前:不明なデバイスさん [2008/02/08(金) 07:58:24 ID:YoHKP6tC]
>>198 索引の更新日付は収容ファイルの更新で変更になる、
だから索引の更新日付をチェックして前回バックアップした日付以前なら
その索引直下に収容のファイルは対象外にできる、
そうすれば処理時間は一桁以下にできるのでは。

261 名前: ◆YtPQzYyEH. [2008/02/08(金) 15:40:09 ID:C4+Xg+NF]


262 名前: ◆JuFLxjEbXg [2008/02/08(金) 15:42:03 ID:C4+Xg+NF]


263 名前:login:Penguin mailto:sage [2008/02/08(金) 16:39:10 ID:lO2z0Hih]
NTFS自体は機能とパフォーマンスを考えたら
PC用のファイルシステムではトップクラスじゃねーかと思う
大元のHPFSが優れていたんだろうな

しかしNTやVistaでさえその機能をきちんと使っていない点でクソ
それとフラグメント化が激しすぎるのもクソ

HFSは褒める部分を探すのに苦労して苦労して、それでも何も見つからないくらいにクソ
さらにそれを告げると信者が火病起こしてわめきだすのがさらにウザくてクソ

ext系は、とりあえず動きますよって段階では不満は無いんだが
それ以上のものでもないし、お世辞にも優れた部分は見出せない
偉大なる平凡

xfsは、こんなもんタダで使わせてもらって本当にいいんスか?って感じだな

jfsは知らん

reiser fsはこれからどうなっちゃうの?って感じ




264 名前:login:Penguin mailto:sage [2008/02/08(金) 16:49:38 ID:B7rrj2AA]
NTFSは異常終了無しで半年使って、chkdskかけたら数千ファイルのaclが吹っ飛んだことがorz
FSが問題なのかどうか微妙なラインだが手痛かった。

xfsはcronでデフラグかけてるといい感じでうごいてる。
reiserは・・・ボリュームでかいとマウント時にものっそ時間かかるんだが・・・

265 名前:login:Penguin mailto:sage [2008/02/08(金) 18:25:44 ID:WpMOTmXO]
xfsは古いマシンで使うぶんには良いんだけどね。
新しいserverに入れる気はおきないな、mlみてたら怖くて。

266 名前:login:Penguin mailto:sage [2008/02/08(金) 18:42:58 ID:PGSC+VCd]
>>264
それはどんなファイルシステムでも書き込んだ後1度も読み取りもしなかった領域が
不良セクタ化したらウンコーッ って話だろ。

267 名前:login:Penguin mailto:sage [2008/02/08(金) 18:47:17 ID:oKxB/QKg]
>>265
新しいマシンだと何か不具合出るの?

最近のコードが安定してない、って話なら分かるけど。

268 名前:login:Penguin mailto:sage [2008/02/08(金) 22:53:36 ID:5Qp7toYJ]
xfsはシュルシュル、reiserfsはヌルヌル。
性能いいのはreiserなんだろうけど、
xfsはそこそこ性能を発揮して低負荷。

>>259
あーあー、そうだったそうだった。
月イチxfs_check使ってるので忘れてたわ。

269 名前:login:Penguin mailto:sage [2008/02/09(土) 11:55:22 ID:I5g2yu0o]
>>264
MSKB831374、831375、327009、873437とか該当してなかった?

270 名前:login:Penguin mailto:sage [2008/02/09(土) 12:20:37 ID:woPPxICV]
xfsはファイルの削除が遅い。カーネルツリー削除するのに時間がかかるよー。

271 名前:login:Penguin mailto:sage [2008/02/09(土) 13:11:25 ID:aL9fnslD]
削除なんてバックグラウンドでやらせときゃいいじゃん

272 名前:login:Penguin mailto:sage [2008/02/09(土) 13:18:17 ID:JxDwlQM6]
>>266
いやRAIDだし不良セクタ関係ないw
ハード障害に対するFSの耐久性の話ではない。

273 名前:login:Penguin mailto:sage [2008/02/10(日) 21:20:25 ID:zTNy08k4]
3wareのRAID板で1TB*3のRAID5を構築したのですが、
Linuxのファイルシステムとしてデータ領域に適しているのはどれになるんでしょうか?
CPUはGeodeNXのDualなのでパワーはあまりありません。メモリは2GB積んでます。

reiserfsとXFSとで検討の枠を絞ってしまっていいものか、
最近のトレンドが分からないのでご意見ください。
現状持ってる数年前のイメージでは以下の感じ。

XFS
○ ファイルシステムが大きくてもマウントが早い
○ あまり負荷がかからない
○ reiserfsより早い
× ファイルの削除が遅い
× fsckちゃんとしてるのかよく分からない・・・

reiserfs
○ ファイルシステムの縮小が唯一できる
× ファイルシステムが大きくなるとマウントが遅い

最近はどうなんでしょうか?



274 名前:login:Penguin mailto:sage [2008/02/10(日) 21:29:22 ID:GwVP/ZS2]
>>273
個人で使うなら大して変わらないから好きなの使えば?


275 名前:login:Penguin mailto:sage [2008/02/10(日) 21:33:29 ID:BEDS9Otr]
個人で1TBx3か?すごいな






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<225KB

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