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

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

[前50を表示]
150:login:Penguin
07/12/08 02:37:44 YDy//UIh
ところで、NTFSが遅いのでLinux+sambaに置き換えようと思っているのだが、
ファイル数とパフォーマンスの比較ベンチみたいなデータ掲載してるサイト有りませんかね
/home的なファイル群なのでパーテ多数作って細分化したら速度落ちないかなぁと期待してるんだけど。
xfsが巨大ファイルに強いってのは見たことあるんだけど、ファイル数での得手不得手ってどうなんでしょ。

151:login:Penguin
07/12/08 02:54:59 ELorHOyo
>>149
incron+今使ってるバックアップツール
じゃだめなのか？

152:login:Penguin
07/12/08 03:57:20 sU/Rcdj4
>>151
イベントが起こるごとにプロセス起動してたら、
せっかくの低い負荷が台無しになりそうな予感。

incron
URLﾘﾝｸ(inotify.aiken.cz)

イベントを受け取って、指定されたファイルに
イベント名とパスをひたすら出力するデーモンと、
そのファイルに書かれてるパスをバックアップするツールを
組み合わせるとかが妥当かな？

そうすれば好きなバックアップツールを使えるし、
負荷が低い深夜とかにバックアップさせることも出来るし。

153:login:Penguin
07/12/08 04:29:16 AOgHL0gM
てか、バックアップ対象のリストを作るだけならincron自体がいらないじゃん。
好きなバックアップツールだけをつかって負荷が低い深夜に(ry

154:login:Penguin
07/12/08 04:35:29 sU/Rcdj4
>>153
いやいや、それが最近の容量が大きいHDDだと、
一晩じゃバックアップできないんだよね。
手持ちサーバだと、差分バックアップしても10時間ほどかかってる。

そこでイベント処理で素早くできないかなと。

155:login:Penguin
07/12/08 04:50:40 AOgHL0gM
>>154
ファイルシステムレベルでのスナップショットがいるんじゃない?
とふってみよう。

156:login:Penguin
07/12/08 04:56:58 sU/Rcdj4
>>155
確かにスナップショットは欲しいけど、
本稼働サーバでXFSを試すほどではないかなー。

157:login:Penguin
07/12/08 06:02:13 AOgHL0gM
>>156
更新をIN_ONESHOTで監視してイベントを受け取ったらデイリーバックアップ
ってことにすればいいんじゃねぇと思ったけど、肝心のinotify(7)って、
監視イベントを踏んだ方はイベントを受け取るプロセスをただ起こすだけで、
処理をじゃんじゃか続行してかねーか?

158:login:Penguin
07/12/08 11:54:13 7rFxjzQG
>>149
バックアップとはちと違うかもしれんがこんなのか
URLﾘﾝｸ(freshmeat.net)

159:login:Penguin
07/12/08 13:58:48 fXv3+El5
inofityって監視したい対象ごとにinotify fdに追加していかなきゃいかんから
システム全体の全ファイルをモニタするのは無理。

欲しいのはVFS hookなんだけど、LSMとかkprobesでモニタするような処理を
挿入できるのかなぁ。

160:login:Penguin
07/12/08 17:21:09 9+lQmPMD
>>154
それrsyncで普通にバックアップした方が結局速くなったりしない？

161:login:Penguin
07/12/08 18:03:30 sU/Rcdj4
>>158
おっ、やっぱりあったね。

>>159
まじで・・・。
トップディレクトリだけじゃダメなんだ？

>>160
今rsync使って10時間。
rsync 3.0でメモリ使用量が激減するらしいので、
そうなれば少しは早くなるかなとは思うけど。

162:login:Penguin
07/12/08 19:42:14 AOgHL0gM
>>159
mmap(2)してるやつまで考えると頭が痛くなりそうな気がする・・・

163:login:Penguin
07/12/10 09:05:05 1o7EIMpK
>>146
backup/restoreしたらリンクが切れそうだ

164:login:Penguin
07/12/16 22:42:42 kEiA0RYk
同時アクセスに強いFSって今だとどれ？

165:login:Penguin
07/12/17 00:22:30 HS8oigxL
>>164
read に関してページキャッシュに乗ってればどれでも一緒じゃないか？
とコードも見ずに言ってみよう。

166:login:Penguin
07/12/17 01:55:43 RktuIZ7Z
ヘッドシークが短くなるよう設計してる(らしい)ReiserFS

167:login:Penguin
07/12/17 05:01:49 sg1FvI6J
その手の話は下でLVMやmdなどが動いていたら、fsレベルで何をやってもほとんど無意味じゃない?
fsレベルで下位のデバイスを直接面倒見るようにしないと、あまり高級なことはできなんだよなぁ。

168:login:Penguin
07/12/17 10:14:55 xMRdJbZY
それってI/O schedulerの仕事な気がする
ReiserFSはnoopと組み合わせたときに最高のパフォーマンスになるのだろうか

169:login:Penguin
07/12/18 01:29:57 +yZejH3O
もし
FSに与えられたボリュームの先頭と末尾にFAT的なものを設置して頻繁にsyncをかける、
などというFSがあったらやはり遅いのでは？
よくある環境で遅くなりにくいFS実装というのはありだろう。実際にどれがどうなのかは知らんけど。
同時アクセスつーても大雑把すぎるが、エントリのリストアップが高速なFSはWin向けによさそうかな

170:login:Penguin
07/12/18 04:18:07 6DnGK8YD
じゃあtmpfsが最強ってことでおｋ？

171:login:Penguin
07/12/18 09:57:01 stAupCCv
次点はReiser4な

172:login:Penguin
07/12/19 03:03:55 ICj0cKZP
Resier4そんな速いのかw
ext2で中途半端にキャッシュに乗った状態はすこぶる遅いと表明しておこう
ext3は挙動がよくわからない

173:login:Penguin
07/12/19 09:37:18 FtoZ4/4Y
>>172
>ext2で中途半端にキャッシュに乗った状態はすこぶる遅いと表明しておこう
何今更ネタを披露してんだ？

174:login:Penguin
07/12/20 06:22:34 vEhWN4uA
NTFSはもっと遅い

175:login:Penguin
07/12/30 13:51:28 1u1is7/Z
ちょっと前にイベント処理の話し出てたけど、
Mac OS Xは↓こうなってるらしい。翻訳もしてくれた人がいた。
URLﾘﾝｸ(arstechnica.com)
ｽﾚﾘﾝｸ(mac板:54-63番)

なかなかおもしろいね。
Be OSの方もどうなってるのか気になるなー。

176:login:Penguin
07/12/31 01:38:48 u9rDnk0D
ext3の500GBのHDDに500M～2GBぐらいのTV録画のmpegファイルを適当に放り込んでいたら一杯になったので、
もう一個SATA|IDE-HDDを買ってきてUSBでつないでバックアップつーか要保存のだけ
そっちに整理することにしたのだが、ファイルシステムは何がいいでしょうね?
保存用なので、HDDの利用効率(ext3はちょっと目減り激しい気がす)と壊れにくいのがいいのだけど、
場合によってはUSBで直付けしてWindowsでも見れるntfsもありかなと思っているんだけど。

177:login:Penguin
07/12/31 02:21:15 bruoMmTv
btrfsで。

178:login:Penguin
07/12/31 02:31:26 u9rDnk0D
>>177
ありがとう。調べてみます。

179:login:Penguin
07/12/31 02:49:08 +0ONQ7NM
btrfsはまだアルファ版では？

180:login:Penguin
08/01/12 02:03:46 jzLk1uOI
>>175
Appleも日本語リファレンス出したよ。

ファイルシステムイベントプログラミングガイド
URLﾘﾝｸ(developer.apple.com)

181:login:Penguin
08/01/12 02:29:53 Bx7hU4VM
板違いの話でなんでざーとらしくageちゃうんだろ・・・。
いや、触ったら連中の思うツボ。ここは触っちゃいけないんだったな。くわばら、くわばら。

182:login:Penguin
08/01/12 05:25:06 MhamVZBR
住人気取りきめぇ

183:login:Penguin
08/01/12 05:29:58 jzLk1uOI
>>182
住人だし。
イベント処理を使ったバックアップが出ないかなーと思ってるから、
参考になるかなと思って貼っただけ。

184:login:Penguin
08/01/12 05:38:03 SErII+Xc
気にも留められずに無視されるよりは、たとえ嫌われてでも意識してもらえる方がマシ…とかね

たとえウザがられようともMacやAppleという単語を目に触れさせるようにして、
1000人に一人でも10万人に一人でもいいから
「でもちょっと調べてみるか」くらいのアホが出て来ることを期待してるんだよ

自分たちの何十倍も巨大で、そしてその殆どが自分たちに対して興味すら抱いていない場合に
最も有効な戦略は、まずウザがられて叩かせることなんだ

ほんの10年前、2chができる前に、韓国や北朝鮮や、在日の話なんて誰も知らなかっただろう？
今では2chに来る人の間では、ほとんど常識になっているよね。
必死に彼らを叩く嫌韓厨たちは、連日「韓国」」「朝鮮」「在日」といった単語を
宣伝して回っていたというわけだ。憎悪に駆られて毎日膨大な時間を、韓国ニュースとかを漁ってね。

Appleも、同じ事をやり始めた。いくらメリットを説明しても、メッセージが届かなければ宣伝にならない。
まずはちょっとひと揉みしてアンチを生み、彼らに宣伝を手伝ってもらおう。…今は、そういう段階なんだよね

185:login:Penguin
08/01/12 06:01:06 jzLk1uOI
しかしこれだけストレージが大容量化されてくると、バックアップが大変。

HDDの障害はRAID構成で対処できるけど、
RAIDコントローラーの障害、ファイルシステムの破損は、
結局外部メディアにバックアップしておくしかない。
もし落雷や火事にまで対応するのなら、ネット経由でのバックアップが必要。

しかし常にLoadAverageが高いサーバだと、
バックアップのために割けるCPUリソースがない。
そこで、イベント処理型のバックアップシステムが必要とされてると思うんだけど。
とくにSANなどの外部共有ストレージが使えない低コストが求められる環境だとなおさら。

そういう需要って少ない？

186:login:Penguin
08/01/12 06:37:11 bmbAU9+b
スレ違いだが……

>>184
それで嫌韓連中を増やしたことが韓国のメリットになったのか？
アップルもしくはその支持者の戦略だとするなら、まずそこを
検討しているはず、と思うのだが。

187:login:Penguin
08/01/12 06:57:51 SErII+Xc
>それで嫌韓連中を増やしたことが韓国のメリットになったのか？

韓流ブームはTVと週刊誌で成立したものだと思ってるクチ？
その下地づくりが何時から始まったのか、調べてごらんよ

188:login:Penguin
08/01/12 07:07:04 bmbAU9+b
>>187
なにを示唆したいのか、さっぱり分からん。
てか、「ほのめかし」に終始して会話する気ないでしょ。

189:login:Penguin
08/01/12 07:22:17 SErII+Xc
理解する気がないくせに「会話する気がない」って何様

190:login:Penguin
08/01/12 10:50:20 4BgmnGqv
>>185
真にバックアップの必要なデータって極わずか。
それらが大量にあるというなら、それなりの
コストを払ってSAN上で２重化すれば。

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

191:login:Penguin
08/01/12 11:09:04 IDm5jJbB
>つかCPUマシンとI/Oマシンくらい別にすれば。

なんだその表現ｗｗｗ

192:login:Penguin
08/01/12 11:27:17 jzLk1uOI
>>190
SANが導入できる予算があれば苦労しないわけで。

しかしSANってかなりファイルアクセスコスト高いから、
大量の小さいファイル（HTMLとか）で
500GBとか占めてるサーバの差分バックアップ取ろうとしたら、
かなり時間掛かるんじゃないだろうか。
ブロックコピーだったら問題ないけど。

193:192
08/01/12 11:29:24 jzLk1uOI
SANはSANでも共有ファイルシステムを使った場合の話しね。

194:login:Penguin
08/01/12 11:52:55 4BgmnGqv
>>192
>大量の小さいファイル（HTMLとか）で
>500GBとか占めてるサーバの差分バックアップ取ろうとしたら

それらが本当にバックアップ対象なの？
差分とる必要があるなら、差分がとりやすいような構成に
するんじゃないのか。何も考えずに/varに500GBとか
やってるんすかね。

195:login:Penguin
08/01/12 11:55:47 yT37g0aU
>>185
そんなだらだらとしたバックアップが実際に役に立つと思いますか？
データの一貫性を保つためには、きちんと決められた時点のデータがすべて揃わないと何の意味も無いんですよ。
あなたみたいな、ハードウェア的な要件だけでしか物事を考えられないSEは邪魔なだけですよ。

196:login:Penguin
08/01/12 12:26:21 jzLk1uOI
>>194
HTMLの場合もあれば、2chのdatファイルのようなこともあれば、
Maildirのメールファイルのこともある。
HTMLやMaildirの場合はディレクトリ構成とかをこっちの自由にはしにくいから、
全体で差分バックアップを取る必要がある。

>>195
DBのバックアップじゃないから、OK。
HTMLの場合なんかだと、スナップショットを取る必要すらない。
決めつけの頭固いSE乙。

197:login:Penguin
08/01/12 12:30:53 iYG31qhb
Appleのドキュメント見に行ったけど、バックアップに使うというのは、
イベントによってファイルシステムのある瞬間の状態をとれるということだよね。
スナップショットをとってのバックアップだったらLVMとかでLinuxで既にやっているし？
あまりLinuxで似たような実装するとか(効果や労力の点で)考える必要ないんじゃない？
と思ったけど、そういうこととは違うの？

198:login:Penguin
08/01/12 12:43:43 jzLk1uOI
>>197
いや、違う。
例えば100KBのファイルが5000000個あるボリュームがあって、
それの差分バックアップを取りたい場合、前回との差を調べるだけで、
１～５時間ぐらい（バックアップ先やLAによって異なる）かかる。
でも実際にはほとんど更新されてなかったりして、
ファイルコピー自体は10分ぐらいで終わってしまったりする。

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

ってことをやりたい。

199:login:Penguin
08/01/12 13:07:29 iYG31qhb
ionotify APIを使えばできるようになるのかなあ
URLﾘﾝｸ(www.linux.or.jp)
うーん、これを利用するプログラムなら、もうあった気がする。
というかそのプログラムの説明でこのAPIを知った筈なんだが。

200:login:Penguin
08/01/12 17:24:53 Y+I93RRs
lsyncd
URLﾘﾝｸ(www.pri.univie.ac.at)
これか？

201:login:Penguin
08/01/12 17:37:47 zybZJIGE
で、ループしてinotifyは監視できるノード数に限界があって・・・、で戻る。
inotifyで/以下監視しようとするとさくっと死亡します。
ただし、/home以下ならユーザー数や利用のされ方しだいでは可能。

現実的な策としてAppleの実装は参考になるよ。
もっとも根底からinotifyとは違う方式なので、単にログサーバが
別途あればいけるというようなことにはならない＞Linux

202:login:Penguin
08/01/12 17:56:05 Bx7hU4VM
>>198
> HDDの障害はRAID構成で対処できるけど、
> RAIDコントローラーの障害、ファイルシステムの破損は、
> 結局外部メディアにバックアップしておくしかない。
> もし落雷や火事にまで対応するのなら、ネット経由でのバックアップが必要。

よくわからんが、その「どのファイルいぢったかイベントドリブンでメモしときましょう型」
バックアップってさ、結局そのメモスレッドが走ってるCPUマシンが障害起こしたら
おしまいじゃねーの?
バージョン(世代)管理型のバックアップでもないようだし
RAIDコントローラーの障害を心配して、RAIDにしない理由がいまいちわからん。
RAIDコントローラーを一枚(or一台)余計に
買って使わないで保存しとけば、RAIDでOKじゃね?

203:login:Penguin
08/01/12 20:48:27 1iC8xxCD
>>202
ID:jzLk1uOI はRAIDを使わないとは言ってないのでは？
RAIDがあってもバックアップは大切。
そのバックアップを早くしたいって話なんじゃないの？

204:login:Penguin
08/01/12 22:13:37 jzLk1uOI
>>201
同意。

>>202
203の通り。

>>203
代わりのレスあり。

205:login:Penguin
08/01/12 22:16:35 4BgmnGqv
>>204
金も知恵も使いたくないなら
RAID１やってバックアップとるとき抜いて、
別マシンで差分とればいいんじゃね？

206:login:Penguin
08/01/12 22:23:07 jzLk1uOI
>>205
RAID1の片方のHDD抜いたら、
ホットスペアディスクに転送始まって、
終わるまで重くてしょうがないよ。
それにわざわざデータセンター行かないとできないし。

207:login:Penguin
08/01/12 23:01:22 Bx7hU4VM
>>204
RAID5/6でもダメ?

バックアップ取りたいってのは分かる気がするけど
んーとさ、これってファイルシステムレベルで
やる話なのかな?って思った。

アプリケーションレベルで保存先二つにするとか、
ユーザのログアウト時にユーザの書き込み範囲だけ
バックアップ同期するとかそんなんでもよさげな気がす。

208:login:Penguin
08/01/12 23:28:26 gMk/W/4K
>>207
というかブロックレベルでやればいいよな、と思った。なに？EMC高い？AX4なら100万以下だぜ

209:login:Penguin
08/01/12 23:43:07 Bx7hU4VM
>>208　そりゃそれなら文句ないだろうけど。
ここの話で、確かにもう少しそういうものの小規模、低コストなものは需要があるのかもしれんね、とおもた。

210:login:Penguin
08/01/12 23:58:53 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
08/01/13 10:03:01 Nollm+Al
>>210
基本的に、クラスタで両方からいっぺんにアクセスされる可能性があるものの場合は
バージョンをあわせなきゃダメだろ。バージョンが違うと言うことは機能に違いが
あるということなのだから。

212:login:Penguin
08/01/13 13:45:13 uE2Jrzt9
>>204
URLﾘﾝｸ(nzfug.nz.freebsd.org)
FreeBSDの話だけど。
ZFSでsnapshot作って、前回のsnapshotとのバイナリ差分をリモートに送信・同期させる方法。

213:login:Penguin
08/01/13 14:04:33 weLbJnIm
そういえばUNIXマガジン買ったやつはいないのか。

214:login:Penguin
08/01/13 14:42:06 T1kxn9Tz
>>208
そのAXなんちゃらEMかんちゃらも高いからなあ。
なら自分は手順覚えれば無料のを使った方がいいや。

215:204
08/01/13 22:38:13 PiB7mojI
>>207
> アプリケーションレベルで保存先二つにするとか、

Webアプリが出力したデータをバックアップするときは、この方法使うこと多いね。
けど、FTPでアップされたファイルとかだと
デーモンをいじらないと出来ないから、キツいねー。

>>212
おっ、これ理想的かも。

216:login:Penguin
08/01/14 00:20:29 qmocvwzd
NetBSD上でだけど、ファイルの書き込みや移動、削除が発生すると
ファイルパスを通知するファイルシステムを昔作ったよ。
理由はmknmzが毎度毎度ディレクトリを全部スキャンして遅かった
からなんだけど…。
既存のファイルシステム(overlay filesystem)のコードを流用したから、
結構簡単に作れたよ。

Linuxでも検討してみたけど、ファイルシステムの設計がスタッカブル
じゃないんで面倒臭くなってやめちゃったなあ。
今ならFUSEとunionfsを駆使すれば、同じようなことでできるんじゃないかな？

217:login:Penguin
08/01/14 00:37:09 6n5zEajJ
aufs使えばできそうだな。

218:login:Penguin
08/01/14 02:19:06 qPxdU3yy
vfsで実装

219:210
08/01/15 02:26:55 BF3bHG9k
>>211
やっぱそうですよね、合わせないとダメですよね・・・
ubuntuの方を1.27にしてみます

ocfs2とgfs2の違いは相変わらずよく分からん、ocfs2の方が設定簡単そうぐらいしか

220:login:Penguin
08/01/15 03:29:14 Ar++HS05
SDカードのFATエントリなんか他のエリアと比べて
何倍も書き換えられると思うんだけど
フラッシュメモリの使い方として問題ないの？

221:login:Penguin
08/01/15 03:30:48 jvp0V+W6
今はフラッシュメモリ側で散らす機能があるでしょ。

222:login:Penguin
08/01/15 03:40:12 Ar++HS05
ほー、なるほど賢いね。
カードに直接そういう機構がそなわってるってこと？
それともカードを扱う使用機器のドライバ側ってこと？

223:login:Penguin
08/01/15 03:42:21 edpzbljx
カード側で持ってるよ。アルゴリズムは各社の極秘中の極秘だそうだ
まあカードの書き換え速度や寿命に如実に影響する肝の部分だしな

224:login:Penguin
08/01/15 03:54:19 Ar++HS05
なるほどありがとう。
しかしそうするとメモリーカード上のフラグメンテーションって
純粋に仮想的なもので実測には影響しないのかな。

225:login:Penguin
08/01/15 03:57:55 edpzbljx
フラッシュメモリはSDRAMみたいにバーストリードで速度が上がるとかいう要素は無いだろう
ランダムリードと言っても元々数KB～数十KB単位のセル単位で読み書きだし

そのセルが物理的に離れた箇所にあったとしても、スピンドル回してヘッドがギコギコ動く訳じゃないから
どれだけアクセス時間がかかるかとかはほとんど誤差の領域じゃないかねえ
まあ俺も素人だから正味のところはわからんが

それよりもコントロールロジックの処理速度の方が遥かに影響が大きそうだ

226:login:Penguin
08/01/15 04:23:10 RzvkwwJj
知ってる方がいたら教えてほしいのですが、ext3のdata=journalのモードってのは
本当にフルデータジャーナリングなのでしょうか。メタデータだけじゃなくて、データ
の変更についてもジャーナルログに書き出してるんでしょうか。

大抵の文書には、
「フルデータジャーナリングじゃ」だから「2度データが書き出される」と書いてあるのですが、

@ITの記事によると「journalモードではディスクへの書き込みが完了したことを確認してから
ジャーナリングの記録を行う」とありまして、同期書き込み＋メタデータジャーナリングのよう
な解説をしてあります。これだとデータの書き出しは1度だけです。
URLﾘﾝｸ(www.atmarkit.co.jp)

詳しく解説してあるので、@ITの方が正しいような感じがするのですが、どんなもんでしょう。

それからもう一つ疑問なのですが、フルデータジャーナリング使うぐらいなら
同期マウントした方が良い気がするのですが間違ってますか？
（同期マウントでもメタデータの更新中に停電したらアウト…なのかな）

アホな質問ですいません

227:login:Penguin
08/01/23 01:52:59 N7D3q8Og
ここで言う同期マウントって例えば？

228:login:Penguin
08/01/23 13:49:47 1HOl8oN3
-o sync, dirsync

229:login:Penguin
08/01/23 14:27:45 l6jXIqfH
同期モードでmountしている状態でもクラッシュしたらfsckが必要ですし
実現できる機能が違いますよね

230:login:Penguin
08/01/25 05:13:31 V+xKWgCR
そもそも同期モードで書いてる途中で落ちたとして、
どこまで何を書いたかは誰が覚えてるんだろうねぇ？

231:login:Penguin
08/01/25 19:51:15 OAhQQFKa
誰も覚えていない。
書き込みそのものがなかったものになるだけ。

232:login:Penguin
08/01/26 07:10:51 nkamkNao
それはジャーナル有る場合だろ

233:login:Penguin
08/01/26 07:50:09 8OpwyOTH
はあ？

234:login:Penguin
08/01/26 14:24:53 nFnPAV3G
同期・非同期とトランザクションの区別はつけようぜ。

235:login:Penguin
08/01/26 15:24:51 Pvih2f3X
>>232
fsckでなかったものにされるんじゃね？
ジャーナルなんて関係ないでしょ。

236:login:Penguin
08/01/26 15:53:50 8QyNar63
>>235
fsckすると残りのジャーナルを適用することもある。
どっちが整合性を保ちつつデータを保全できるかによるようだ。

237:login:Penguin
08/01/26 17:14:55 X0RlC9mR
ちょっとまて >>226の
>フルデータジャーナリング使うぐらいなら同期マウントした方が良い
かどうかだろ
ジャーナリング無しで同期書き込みしたらfsckでロールバックかかるってこと？？

238:login:Penguin
08/01/26 17:25:57 IqVOKU/f
ちゃんと流れ読めよ

239:login:Penguin
08/01/26 19:00:37 Pvih2f3X
>>236
なんでそうなるのか、それがわからん。
同期の場合は、sync（）にしろwrite（）にしろ、書き込みがすべて終わるまで戻ってこないんでしょ？
対象がジャーナルFSであっても。

>>237
fsckで行う作業をロールバックというな。

240:login:Penguin
08/01/26 21:51:13 X0RlC9mR
状況がよく分からんのだが、ファイルの内容書き換え中に落ちたとして、
fsckでどうやってロールバックされるわけ？
>>230な状況になるんじゃないのか

241:login:Penguin
08/01/27 01:29:39 LrB7nbuV
RDBMSの場合は、SQLレベルでの論理的な操作すべてが記録されているから、
直前のバックアップデータに対してログをリプレイすることで、完全復旧ができるというわけだが、
ファイルシステムに当てはめて考えれば、バイトレベルの操作すべてに対してログが採られていなければ、データの中身までは保障できないということになる。
現実的には、そんなことしてたらログの量がとてつもなくなるから、到底無理な話。

ジャーナルFSが復旧処理でやっていることは、通常のfsckがすべてのファイルに対して実行する検査を
ログをなめることで省略しているにすぎない。
当然、正常に閉じていないファイルは、問答無用でlost+found逝きとなる。
これをロールバック/フォワードなどという言うには違和感あるでしょ？

242:login:Penguin
08/01/27 03:02:00 i1WeOFxf
>>241
データについてもする場合はopen以後のwriteは別領域に書いて、
適当なタイミングでFS構造からの参照を付け替えればいいだけ。
この場合、write中にクラッシュした後の復旧でロールバックする。
ただし XFS とかの実装だとcreat自体はコミット済みだから
０バイトファイルが残ってくれたりとある意味困った挙動になったり。

さらに進んでNTFSとかreiser4ではアプリ側からトランザクション性を
制御した書き込みができる（た？）はずだけど、どういう形なんだっけ？

あとfsckがやってるのは正常に閉じられなかったファイルではなく、
参照があるのに参照先がないとか、参照がないのに実体があるとかの
FS構造としての不整合状態をブロックをなめて発見したものを
lost+foundに集めたりクリアしたりしてるだけで、閉じられなかった
ファイルを救ってるわけではない。

243:login:Penguin
08/02/02 17:24:24 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
08/02/06 21:12:32 xB+Vp2Cl
トーバルズ：OS XはVistaよりマシ、でもファイルシステムはゴミ
URLﾘﾝｸ(japanese.engadget.com)

ktkr

245:login:Penguin
08/02/06 21:24:53 xsQFoZY7
誰か言ってやってくれ
LinuxはServer2008よりマシ、でもファイルシステムはゴミ

246:login:Penguin
08/02/06 21:35:04 CEBTMN4n
>>245
いやそれは逆だろ。
ファイルシステムはマシだが・・・。

247:login:Penguin
08/02/06 21:43:01 bycraF9D
NTFSってどうなん？

248:login:Penguin
08/02/06 21:45:17 AbBwRF41
ゴミ

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

250:login:Penguin
08/02/06 21:59:15 MW2Uiq4L
>>249 それ賛同

251:login:Penguin
08/02/07 00:55:39 Jh0j2rM7
リーナスってバカだな

252:login:Penguin
08/02/07 03:33:18 UdsqPHwZ
ntfsでファイルがぶっ飛んで破片も出てこないのはプログラムが悪いの？

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

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

254:login:Penguin
08/02/07 11:16:04 JbuBRM/5
>>253
どこかに0バイトのファイルが転がってるかもよ。

255:login:Penguin
08/02/07 17:47:13 nagQT8db
ちなみにどういう落とし方したの？

256:login:Penguin
08/02/07 18:16:17 lsDyIYji
酒を飲みつつ恋愛論を語った

257:login:Penguin
08/02/07 18:26:42 MhI2GJBO
たしかにntfsだとぶっ壊れそうだ。
あとできちんとf*ckしとけよ。

258:login:Penguin
08/02/08 02:06:16 5Qp7toYJ
いったいなんのスレだよw

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

259:login:Penguin
08/02/08 02:20:17 SRnPVqDy
>>258
昔のxfs_fsck.c

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

今はshell scriptになったな。

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

261: ◆YtPQzYyEH.
08/02/08 15:40:09 C4+Xg+NF

262: ◆JuFLxjEbXg
08/02/08 15:42:03 C4+Xg+NF
な

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

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

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

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

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

jfsは知らん

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

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

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

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

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

267:login:Penguin
08/02/08 18:47:17 oKxB/QKg
>>265
新しいマシンだと何か不具合出るの？

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

268:login:Penguin
08/02/08 22:53:36 5Qp7toYJ
xfsはシュルシュル、reiserfsはヌルヌル。
性能いいのはreiserなんだろうけど、
xfsはそこそこ性能を発揮して低負荷。

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

269:login:Penguin
08/02/09 11:55:22 I5g2yu0o
>>264
MSKB831374、831375、327009、873437とか該当してなかった？

270:login:Penguin
08/02/09 12:20:37 woPPxICV
xfsはファイルの削除が遅い。カーネルツリー削除するのに時間がかかるよー。

271:login:Penguin
08/02/09 13:11:25 aL9fnslD
削除なんてバックグラウンドでやらせときゃいいじゃん

272:login:Penguin
08/02/09 13:18:17 JxDwlQM6
>>266
いやRAIDだし不良セクタ関係ないw
ハード障害に対するFSの耐久性の話ではない。

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

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

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

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

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

274:login:Penguin
08/02/10 21:29:22 GwVP/ZS2
>>273
個人で使うなら大して変わらないから好きなの使えば?

275:login:Penguin
08/02/10 21:33:29 BEDS9Otr
個人で1TBx3か？すごいな

276:login:Penguin
08/02/10 21:43:31 GwVP/ZS2
>>275
1TB 2.5万だからちょっとしたおもちゃだろ？

277:login:Penguin
08/02/10 22:46:57 41EqjFSS
1Tx3が2.5万x3
ML115が1.5万

メモリ2Gを0.5万で追加したとしても
9.5万で2TなNASが用意できる時代ですぜ。

278:login:Penguin
08/02/10 22:52:26 kPqZgS0L
知らない間にバカ安になってるな。
うちのノートPCのHDDも取りかえたい。

279:login:Penguin
08/02/10 23:13:04 jaGVAHE6
1Tも入れるものが無い

280:login:Penguin
08/02/11 00:55:40 v/vK9WxC
>>273
どちらが良いとは言わない、だがこれだけは言わせてくれ。

・xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。
・プロセス毎で使えるメモリ量は限られている。(特に32bitな環境では)
・メモリを増設しても、プロセス毎で使えるメモリ量は変わらない。

281:login:Penguin
08/02/11 00:57:39 NXuZoz9l
>>280
>・xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。
すごくフラグメントしてたり、むちゃくちゃになってしまった時に
必要なだけで、普段はそんなに要らない。

もっともcheckやrepairが必要なときは、かなり終わってるけどな。

282:login:Penguin
08/02/11 12:55:43 hHXFn50e
>>281
> > xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。
> すごくフラグメントしてたり、むちゃくちゃになってしまった時に
> 必要なだけで、普段はそんなに要らない。
俺は、良く聞く4MB/i-nodeにつき128MB/RAMという、xfs_repairの昔からの定説から
1TBならi-nodeはおよそこれ位だから、RAMはだいたい1GB的な一般解を>>280は導いてきたと思ったんだが
i-nodeの大きさだけじゃなく、フラグメントも関係あるのか？

俺はツーリングとか、息子の運動会、家族旅行で流し撮りした映像の置き場や、編集用として
WD7500AAKS×4を2410SAでRAID5運用していたわけだが、RAMは1GBしか積んでない
当然中身はGBオーバーの動画ファイル群のみ

だが突然の電源断や、停電などで落ちた際にxfs_checkをかける時でも、これまで一度として
メモリが足りなくなったりしたことはこれまでなかった

俺はこれをエクステントが効いている為に、i-nodeの大きさ自体はそれほど増えていないからだと
理解していた訳なんだが、もしフラグメントが関係しているなら、一度もxfs_fsrをかけたこともなく
使用量も80%を余裕で超えているこのディスクは、相当に断片化しているはずなんだけどな

283:login:Penguin
08/02/11 13:01:33 L4qR2Tu7
フラグメントは関係ない

284:268
08/02/12 02:16:28 XWn0I4iF
>>280
システム移行時にサブ(メモリ256MBのP3)機で1.5TBのxfs_checkしたけど、
メモリ食う仕様忘れててswapディスクなしだと見事に固まったな。

低速ながらswapディスク付けたら一晩ちょいでどうにか終わってた。

285:login:Penguin
08/02/14 10:51:10 U8W3css3
URLﾘﾝｸ(www.smalltown.ne.jp)
おれもxfsってたまに重くなると思ってた。
こういうのもログを別ディスクにしたら性能あがるのかね

286:login:Penguin
08/02/14 10:57:56 S8QS6vkZ
>>285
swapに追い出せないジャーナル用のメモリを他のアプリや
カーネルと取り合いしてメモリ上でスラッシングしている
んじゃないかな。

287:login:Penguin
08/02/14 10:59:02 S8QS6vkZ
だから、高速なディスクに素早くジャーナルを書き出せれば
起きないのではないかと思う。

288:login:Penguin
08/02/16 10:58:54 1+pZMLPj
>>281
xfs_repair,xfs_checkは正常にマウントできなくなった時に使う。
１TB当たり1GBは正解。

ただし、今じゃxfs_repair -L位しか使った記憶ないなぁ

289:login:Penguin
08/02/21 00:04:34 Qe0QvPTZ
SuSEでブート領域を外部ディスクにして使ってます。
その外部ディスクが停止したりしてI/Oが一時的にでも停止すると、
ext3 が即座に Read-only で自動的にリマウントされます。

調べたところこれはext3(ext2)の仕様のようですが、どうにかして
リブートせずに Read-write でリマウントできないでしょうか？
今まで試したことは以下の通りです。

1. mount の remount オプションの使用
2. マウントしたまま fsck をかけた後、1を実施

tune2fs のエラー発生時のハンドリングは Continue になっています。

スレ違いでしたらすいません。

290:login:Penguin
08/03/02 13:54:44 hc9C85N7
1FSあたりのファイル,ディレクトリ数って、増えすぎると速度落ちるよね？
その辺のデータって詳しいサイト無いかな。若しくは影響出やすいFSの体験談とか。
1ディレクトリに大量ファイルってのはまたちょっと別なんだけど。

291:login:Penguin
08/03/02 13:57:47 e0Thmhwp
それはフラグメンテーション

292:login:Penguin
08/03/02 15:02:36 hc9C85N7
あぁ、ファイルの読み取り速度とかディスク速度とかじゃなくて、
ファイルへのアクセス速度(fopen完了までとか)ね。

293:login:Penguin
08/03/02 15:09:57 e0Thmhwp
それもフラグメンテーション

294:login:Penguin
08/03/02 21:13:23 hc9C85N7
なんのこっちゃ・・・
えーとじゃあ、デフラグした状態で。

295:login:Penguin
08/03/02 21:19:19 1ooFJNDl
>影響出やすいFS

FATとかか？

296:login:Penguin
08/03/02 22:01:33 QO19JZJo
実装を別にしてもあれが糞なのは疑いようがない

297:login:Penguin
08/03/02 22:03:01 88VAzaOv
手軽さと互換性をちょっとは評価してもいいとは思うが

298:login:Penguin
08/03/03 14:31:32 olTABkIp
NTFSはドライブ内のファイル数が増えてくると急に遅くなる気はするな
MFT周りなんだろうけどよくわからん
FATは論外として、xfsもファイル数増えるとなんかもっさり。
reiserは結構耐える感じ？まnotailとかのオプションにもよるだろが

299:login:Penguin
08/03/03 15:01:41 JCTvrwL7
単純にindexが肥えていじるのに時間かかるようになるから。
ファイルシステムは大体そういうものだ。

reiserはそういう状況でもそれなりに動く様に設計されとる。

300:login:Penguin
08/03/03 15:08:13 8CT1QtMK
ここまで客観的な数値ゼロ

301:login:Penguin
08/03/03 17:34:55 QQPe3/34
>>290が体験談を望んでるから妥当な流れ
別に有ってもかわまんので書いてくれても良いよ>>300

302:login:Penguin
08/03/03 19:17:19 ic5kxWI3
xfsに変えたら彼女ができました！

303:login:Penguin
08/03/03 20:25:58 i1bQg1Re
reiserfsに変えたら妻が失踪しました！

304:login:Penguin
08/03/03 20:59:30 vUAhW00A
zfsはどうなんだろうね、ｌｉｎｕｘでも早いところつかえるようにならなかね

305:login:Penguin
08/03/03 23:37:31 aMHSs4ys
jfsに変えたらサーバが青いタワー型に！

306:login:Penguin
08/03/04 00:03:47 MG8dmV58
>>305
逆だろ、それ。

307:login:Penguin
08/03/04 00:40:55 mPcUgsuW
>>303
そういや、あれってどうなったんだろ。
保釈されたんかな？殺人容疑だからありえないか。

308:login:Penguin
08/03/04 13:36:55 luMzogFa
Reiserfsってどの程度のファイル数耐えられる？
ext2みたく酷くはないと思うが怖くて使ってない

309:login:Penguin
08/03/04 20:56:04 2F2RseEP
inodeが動的にあれだからなあ。
結構いくと思うけど。

310:login:Penguin
08/03/04 21:53:43 kk4vfn0k
参考までにどぞ。

TimeMachineに頼れない人のための完全バックアップ方法：日経パソコンオンライン
URLﾘﾝｸ(pc.nikkeibp.co.jp)

311:login:Penguin
08/03/16 21:01:35 flqkXLd1
ディレクトリエントリつーの？findしたときに読まれるデータを、
優先的にキャッシュに残しとくFSとかオプションとか無いかね。

312:login:Penguin
08/03/17 10:38:08 4IyCtHoK
それは FS というか単にキャッシュのアルゴリズムでは?

313:login:Penguin
08/03/17 12:26:47 7b6j/OHS
キャッシュバッファのレイヤですな

314:login:Penguin
08/03/17 14:54:29 nm4uxoxm
普通はページキャッシュかブロックバッファと言わないか？
キャッシュバッファだと馬から落馬みたいだ

315:login:Penguin
08/03/17 15:22:06 pTUBucW/
>>311
Linuxならディレクトリエントリキャッシュはあるけど。

316:login:Penguin
08/03/18 01:32:40 jCQs8JOZ
>>314
buffer cacheといいたかったんだろう。

317:login:Penguin
08/03/23 15:41:33 NvqLU+q0
>>316
しかしバッファキャッシュはfindの高速化になんの関係もないので本来の意図は
i-cache, d-cacheではあるまいか？

318:login:Penguin
08/03/23 16:57:13 4i3/VEiN
>>317

通常のファイルシステムでは、ファイル名ってのはdirectory fileに格納されているので、buffer cacheは関係なくはないんじゃね？
むしろdirectory entryのcacheはfindには関係なくないか？
inodeのcacheを使うかどうかもfindのオプションによると思う。

319:login:Penguin
08/03/24 11:41:29 xCc6BPh+
そのへんよくわからんな
Linuxのディスク～fs～buffスレとか無いものか

320:login:Penguin
08/03/28 22:28:36 26zHaioF
UBI File System
URLﾘﾝｸ(kerneltrap.org)

321:login:Penguin
08/03/29 21:41:44 f/e2EUT3
>>320
JFFS2のスケーラビリティーが悪すぎたので１００倍程度では心元ない

322:login:Penguin
08/03/30 04:13:47 GQ0aE0r7
ext4dev は早く正式なext4にならないかな

323:login:Penguin
08/03/30 11:01:12 IoGJIZKZ
ext4絡みでVFS廻り、相当変わってる？

324:login:Penguin
08/03/30 12:32:47 pKiGTBVm
>>323
変わってませんので安心してFUDをお続けください。

325:login:Penguin
08/03/30 14:13:24 o6yKIr3w
ext3はjbdが1スレッドしかいないおかげで、しばしばこいつがボトルネックになったけど、
ext4では改善されるんかね？
XFSみたくノード毎にほしいよね

326:login:Penguin
08/03/30 15:22:11 IoGJIZKZ
いや、最近のxfsのアホみたいな変更の量は、
VFSが変わったせいかと思ったんだが。そうじゃないのね。

327:login:Penguin
08/03/30 20:33:55 hAIGTsTG
>>326
どこも変わってないじゃん

328:login:Penguin
08/03/30 22:09:21 o6yKIr3w
XFSつながりで、話を脱線させると、最近David Chinnerの
Per-superblock unused dentry LRU パッチを評価してるんだけど、
これ、いいな。
だいぶ速くなる

329:login:Penguin
08/04/02 23:36:16 miBB8ivN
raid0とXFS組み合わせたらext2の1/7ぐらいしか性能でなかった。
ﾎﾞｽｹﾃ･･･

チューニングパラメタとかあんの？

330:login:Penguin
08/04/02 23:45:20 MwvMzT8M
>>329
何を書いたかによるんでねぇの

331:login:Penguin
08/04/02 23:47:09 miBB8ivN
>>330
dbenchでのスループット

332:login:Penguin
08/04/02 23:53:19 miBB8ivN
ちなみに本日の測定結果
ext2: 470MB/s
ext3: 150MB/s
XFS: 70MB/s

333:login:Penguin
08/04/02 23:57:54 ljKkX6tm
reiserfs…

334:login:Penguin
08/04/03 00:03:41 itZB1pzN
>>333
LKMLみててビルドエラーしたよん系以外の話題でreiserfsはとんとご無沙汰。
あれはもうダメじゃないか？

335:login:Penguin
08/04/03 00:16:25 5AUHYNuG
話題にならないということは、reiserfs3が安定しているということだ。
よいことではないですか。

336:login:Penguin
08/04/03 00:19:23 XQFAcyR9
多分、JFSも超安定してるんだろうなあ・・・

337:login:Penguin
08/04/03 01:06:02 Ztawo/Fi
>>336
JFSはサンプルが少なすぎるのかもねｗ
まあ、俺はext3に裏切られてから、IBMを信じて使ってたけど。

338:login:Penguin
08/04/05 14:39:51 CsBMf95s
正式ext4マダ～？

339:login:Penguin
08/04/05 17:01:10 gcliPWD0
たぶん福田総理の辞任→新総理誕生とタイミングが同じになると思う。

340:login:Penguin
08/04/05 22:37:23 BOqKZkDS
>>338
正直新FSを名乗るほどは変わってないという印象

341:login:Penguin
08/04/06 12:51:02 2TQbeNBN
ext2→ext3よりは変わってるだろ

342:login:Penguin
08/04/06 17:43:04 Wl/OXr5s
16TBを越えるストレージが必要になるまでは、reiserfs使ってたほうが良くない？

343:login:Penguin
08/04/06 17:49:50 u2gn5b5I
reiserは8TBまで
実際にハマってXFSにした。

344:login:Penguin
08/04/07 21:57:37 QCSgi87J
はよext4でないかなー。
Reiserやxfsはハードの進化に追いついてないし、JFSは死に体だし。

345:login:Penguin
08/04/07 22:04:07 W1D8Pi3p
>>xfsはハードの進化に追いついてないし
kwsk!

346:login:Penguin
08/04/07 22:04:21 jcVZQx+d
ext?がハードの進化に追いついてるかというとそれも疑問符が付くと思うのだが
reiser4の方が近代的でね？

347:login:Penguin
08/04/07 22:09:03 XafXBPQU
死んだ子の年を数えるのは止めようぜ

348:login:Penguin
08/04/07 22:14:16 pnasWVod
...zfs....

349:login:Penguin
08/04/08 08:05:49 vX51nrv+
>>332
＞ちなみに本日の測定結果
＞ext2: 470MB/s
＞ext3: 150MB/s
＞XFS: 70MB/s

ＪＦＳもやってくれー

350:login:Penguin
08/04/08 12:40:57 7jql+r0w
>>345
いまC2D対応やってます状態。xfs使うならPen4以前で。

351:login:Penguin
08/04/08 12:42:54 77bTVWBc
>>350
そのやってます状態のパッチは？

352:login:Penguin
08/04/08 20:06:46 t6pXtMUO
>>350
ああ、開発主体のSGIがスパコン屋さんなので、去年まではIA64メイン、
今年からはx86_64メインだからね。
x86_32 はどうしてもワンテンポ遅れるんだけど、正直それで困ってる人もいないという・・・

353:login:Penguin
08/04/08 21:59:28 kp2pJUVD
>>350
対応って具体的に何するの？
ちゃんとしたSMP対応した時点でマルチコア対応と変わらんし。

354:login:Penguin
08/04/09 11:03:15 XsC9hakW
>>353
普通そう考えるだろうが、そうじゃなかったのがXFSの凄い(?)ところ。

355:login:Penguin
08/04/09 11:21:07 irm1RyJp
ここまで具体的な数値またはコード、０。

356:login:Penguin
08/04/09 13:21:43 XsC9hakW
mm絡みのあのpatchとかlock絡みのあのpatchとか思い浮かぶのはあるんだが、
ゴミの山みたいなpatchの中から探し出してくるのがダルすぎ
定量的に比較したことは無いが、ext3はあれほどpatch多くない気がするがどうなんだ?

次ページ