[表示 : 全て 最新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/


333 名前:login:Penguin mailto:sage [2008/04/02(水) 23:57:54 ID:ljKkX6tm]
reiserfs…

334 名前:login:Penguin mailto:sage [2008/04/03(木) 00:03:41 ID:itZB1pzN]
>>333
LKMLみててビルドエラーしたよん系以外の話題でreiserfsはとんとご無沙汰。
あれはもうダメじゃないか?

335 名前:login:Penguin mailto:sage [2008/04/03(木) 00:16:25 ID:5AUHYNuG]
話題にならないということは、reiserfs3が安定しているということだ。
よいことではないですか。





336 名前:login:Penguin mailto:sage [2008/04/03(木) 00:19:23 ID:XQFAcyR9]
多分、JFSも超安定してるんだろうなあ・・・

337 名前:login:Penguin mailto:sage [2008/04/03(木) 01:06:02 ID:Ztawo/Fi]
>>336
JFSはサンプルが少なすぎるのかもねw
まあ、俺はext3に裏切られてから、IBMを信じて使ってたけど。

338 名前:login:Penguin mailto:sage [2008/04/05(土) 14:39:51 ID:CsBMf95s]
正式ext4マダ〜?

339 名前:login:Penguin mailto:sage [2008/04/05(土) 17:01:10 ID:gcliPWD0]
たぶん福田総理の辞任→新総理誕生とタイミングが同じになると思う。

340 名前:login:Penguin mailto:sage [2008/04/05(土) 22:37:23 ID:BOqKZkDS]
>>338
正直新FSを名乗るほどは変わってないという印象

341 名前:login:Penguin mailto:sage [2008/04/06(日) 12:51:02 ID:2TQbeNBN]
ext2→ext3よりは変わってるだろ



342 名前:login:Penguin mailto:sage [2008/04/06(日) 17:43:04 ID:Wl/OXr5s]
16TBを越えるストレージが必要になるまでは、reiserfs使ってたほうが良くない?

343 名前:login:Penguin mailto:sage [2008/04/06(日) 17:49:50 ID:u2gn5b5I]
reiserは8TBまで
実際にハマってXFSにした。

344 名前:login:Penguin mailto:sage [2008/04/07(月) 21:57:37 ID:QCSgi87J]
はよext4でないかなー。
Reiserやxfsはハードの進化に追いついてないし、JFSは死に体だし。

345 名前:login:Penguin mailto:sage [2008/04/07(月) 22:04:07 ID:W1D8Pi3p]
>>xfsはハードの進化に追いついてないし
kwsk!

346 名前:login:Penguin mailto:sage [2008/04/07(月) 22:04:21 ID:jcVZQx+d]
ext?がハードの進化に追いついてるかというとそれも疑問符が付くと思うのだが
reiser4の方が近代的でね?

347 名前:login:Penguin mailto:sage [2008/04/07(月) 22:09:03 ID:XafXBPQU]
死んだ子の年を数えるのは止めようぜ

348 名前:login:Penguin mailto:sage [2008/04/07(月) 22:14:16 ID:pnasWVod]
...zfs....

349 名前:login:Penguin [2008/04/08(火) 08:05:49 ID:vX51nrv+]
>>332
>ちなみに本日の測定結果
>ext2: 470MB/s
>ext3: 150MB/s
>XFS: 70MB/s

JFSもやってくれー

350 名前:login:Penguin mailto:sage [2008/04/08(火) 12:40:57 ID:7jql+r0w]
>>345
いまC2D対応やってます状態。xfs使うならPen4以前で。

351 名前:login:Penguin mailto:sage [2008/04/08(火) 12:42:54 ID:77bTVWBc]
>>350
そのやってます状態のパッチは?



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

353 名前:login:Penguin mailto:sage [2008/04/08(火) 21:59:28 ID:kp2pJUVD]
>>350
対応って具体的に何するの?
ちゃんとしたSMP対応した時点でマルチコア対応と変わらんし。

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

355 名前:login:Penguin mailto:sage [2008/04/09(水) 11:21:07 ID:irm1RyJp]
ここまで具体的な数値またはコード、0。

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

357 名前:login:Penguin mailto:sage [2008/04/09(水) 13:29:32 ID:P7VWxNnr]
ext4でデフラグがようやく使えるようになると聞いたのですが。まだ未実装だっけか。
しないとパフォーマンス悪いってのはやっぱ、
linuxでは「必要ない」、ではなく「できない」の間違いだったってことですよね。

358 名前:login:Penguin mailto:sage [2008/04/09(水) 13:42:10 ID:KQOYg6Em]
今時のHDDにデフラグって必要ないんじゃないの?

359 名前:login:Penguin mailto:sage [2008/04/09(水) 13:48:54 ID:XsC9hakW]
ext4の本流にはまだmergeされてない。
が、NECの人が頑張っている流れで実装はある。ext3用のも。

ext2/3ではデフラグが必要ないというより、開発当時の環境では、
デフラグのコストが性能の低下より大きかった、という話じゃないかな。
最近のドライブの大容量化や高速化でそうも言っていられなくなっただけ。

360 名前:login:Penguin mailto:sage [2008/04/09(水) 16:46:40 ID:bJQ+WBXU]
どんなに断片化に強かろうが、使っていれば少しづつ断片化していく訳だが
サーバ市場で普及が進んだおかげでLinuxを長期運用する例が増え
比例して断片化の進み具合やその影響も馬鹿にならなくなってきて
それを解消したがる顧客の声もそこそこの規模になり
更にext4は状況によってext2/3より断片化が発生しやすくなってしまった。
このような時代の流れによりNEC開発陣はデフラグツール開発の大義名分をゲット。
金庫番との死闘と末、開発費を捻出させることに成功したのであった。やったね。

こうですか?わかりません><

361 名前:login:Penguin mailto:sage [2008/04/09(水) 17:00:20 ID:KQOYg6Em]
HDD側のキャシュ増やした方がいいような?



362 名前:login:Penguin mailto:sage [2008/04/09(水) 18:30:34 ID:LVCZieeg]
>>360
発想が昭和の人って素敵って感じだね。

363 名前:login:Penguin mailto:sage [2008/04/09(水) 18:46:45 ID:5v+cawCi]
俺デフラグずっと眺めてるの好きなのでぜひグラフィカルなUIを用意してもらいたい。

364 名前:login:Penguin mailto:sage [2008/04/09(水) 23:04:39 ID:HmwSCQL2]
>>363
win98のころのブロックが移動して色変わってくの好きだったのに2kぐらいから
ただの棒になって色変わるだけになってつまんなくなったな

365 名前:login:Penguin mailto:sage [2008/04/09(水) 23:44:17 ID:OcdXE9xM]
ブロックのやつはそれこそDOSな時代からだよ。
あれは趣があった。

366 名前:login:Penguin mailto:sage [2008/04/09(水) 23:57:02 ID:MHOGD1vi]
乗せたらダマス 魔法の絨毯 騙され続けて四半世紀だな

デフラグってプラセボつーか依存だよね。3日開けずにやっている香具師いる。

367 名前:login:Penguin mailto:sage [2008/04/10(木) 00:23:32 ID:A4V/r+Uq]
デフラグを高速化するために最新のHDDを買い、
HDDがフラグメントしないようにデータをあまり書かない。

そんな時代も俺にはありました・・・

368 名前:login:Penguin mailto:sage [2008/04/10(木) 00:40:21 ID:sVUazSs4]
神経質な奴ほどデフラグ中毒になりやすい。

デフラグ中の画面を延々見てる奴。
洗濯中にグルグル回ってるのを延々見てる奴。
両者は似ているようで少し層が違う。

369 名前:login:Penguin mailto:sage [2008/04/10(木) 00:53:04 ID:M4lYQAYA]
defrag中毒のヤシはLFS系のfsつかえばいいのに

370 名前:login:Penguin mailto:sage [2008/04/10(木) 01:30:53 ID:NY5kJFee]
デフラグの画面は人間の生産性を驚異的に落とす最悪のGUIなので
ライフハック(笑)的には真っ先に削除されるべき

371 名前:login:Penguin mailto:sage [2008/04/10(木) 01:49:42 ID:gvIBE6hj]
LFSとか言われてもな



372 名前:login:Penguin [2008/04/10(木) 04:06:43 ID:Gfyr/fVJ]
>>368
洗濯機のグルグルは気持ちが落ち着く
デフラグはイライラする・・真逆

373 名前:login:Penguin mailto:sage [2008/04/10(木) 10:21:47 ID:REpR0D1a]
なんか洗濯機を眺めながら一人で酒を飲んでるって芸人がいなかったっけ?

374 名前:login:Penguin mailto:sage [2008/04/10(木) 10:49:40 ID:H34Gbw9O]
麒麟の非公園生活者の方(川島)だったな。

ちなみに今は洗濯機そっちのけで眞鍋かをりに乗っかってるとか。

375 名前:login:Penguin mailto:sage [2008/04/10(木) 15:59:42 ID:AsPLT2gw]
>>350
C2D対応のソースまだぁ?

376 名前:login:Penguin mailto:sage [2008/04/10(木) 18:46:32 ID:4oJRCPdx]
デフラグはHFS+のように、
自動デフラグ解消機能をFSに埋め込むって案はないの?
良くアクセスするファイルを、HDDの先頭に移動して高速化するって案は?

377 名前:login:Penguin mailto:sage [2008/04/10(木) 19:46:00 ID:g/S3sRn9]
vxfsマンセー

378 名前:login:Penguin mailto:sage [2008/04/11(金) 02:25:29 ID:xdk7g0sU]
>>376
>良くアクセスするファイルを、HDDの先頭に移動して高速化するって案は?

そういう製品もあるよ
ただHDDの先頭は汚染されやすい
(プラッタ上のゴミ等は遠心力で外周に向かいやすい)
ってことを考えると労力の割には微妙だなあと俺は思う

379 名前:login:Penguin mailto:sage [2008/04/11(金) 02:33:15 ID:2V7teuhD]
良くアクセスするファイルってほとんどの期間osのキャッシュ上にあるんじゃないかな?
ブート時の立ち上がりアクセスを連続化とかそういうのはlinuxじゃ難しそうだし、思想的に好かれなそう。

380 名前:login:Penguin mailto:sage [2008/04/11(金) 10:18:34 ID:gfqUbArl]
>(プラッタ上のゴミ等は遠心力で外周に向かいやすい)

どんなファイルシステムだよ、と思ったら物理メディアの話か…

381 名前:login:Penguin mailto:sage [2008/04/11(金) 11:50:29 ID:NtcJovKM]
HDDの中はクリーンでしょ・・・



382 名前:login:Penguin mailto:sage [2008/04/11(金) 12:54:43 ID:xdk7g0sU]
>>381
プラッタとヘッダが接触する→破片が飛ぶ
あと誤解されがちだがHDDは密閉されていないので
埃等の進入も無いわけではない

383 名前:login:Penguin mailto:sage [2008/04/11(金) 14:27:02 ID:NtcJovKM]
>>382
ヘッドが接触した時点でバッドセクタ発生で使用中止するでしょ。
気圧調整のために穴が空いているけど、フィルタシールされているから、
埃は外部から侵入しないよ。

384 名前:login:Penguin mailto:sage [2008/04/11(金) 15:04:27 ID:xdk7g0sU]
フィルタがあるから進入しないというのは暴論だな

385 名前:login:Penguin [2008/04/11(金) 15:32:21 ID:EtOBVwEL]
>>382
昔のHDDと違って今のはヘッドは接触してないでしょ。
といってもμとかそれ以下のオーダーで離れてるだけだけど。


386 名前:login:Penguin mailto:sage [2008/04/11(金) 17:24:52 ID:510mZMoh]
しょっちゅうカコンカコンいってますが何か?

387 名前:login:Penguin mailto:sage [2008/04/11(金) 20:26:13 ID:2qIbW6EC]
破片云々や遠心力云々、
ヘッドの接触を前提に語ってる奴の言葉など、何一つ信用できない。

ちなみに、ヘッドの浮く高さはよく煙草の煙より狭いと言われるが
だからこそ、そのサイズのゴミさえ侵入しないように作られている。

388 名前:login:Penguin mailto:sage [2008/04/11(金) 20:31:20 ID:2V7teuhD]
てかもうSSDになるんだから、ランダムリードのアクセスはかなり無視できるだろう。
書き込みの遅さと読み込みの速さをどううまくカバーできるかとかやってるのかな?
なんとなくだが追記型のが相性良さそう。

389 名前:login:Penguin mailto:sage [2008/04/11(金) 20:34:54 ID:9r4cpd5H]
よくわからんが
コンタクト・スタート・ストップとかで接触するんじゃないの。

390 名前:login:Penguin mailto:sage [2008/04/12(土) 01:21:44 ID:zKuK+tHg]
非動作時等に接触するのは事実だが
そこが回転しているかどうか。

動いていない部分にヘッドが接触して破片がとぶって、
どれほどの衝撃でヘッドが着地するのかと。

391 名前:login:Penguin mailto:sage [2008/04/12(土) 02:04:05 ID:UJnKfLiT]
>>388
現状ではランダムリードが遅いSSDなんて腐るほどある。
今のHDDでMemoryいっぱい積んだ方が安くて速い。



392 名前:login:Penguin mailto:sage [2008/04/12(土) 03:55:16 ID:ddANuM0+]
>>390
>非動作時等に接触するのは事実だが
接触しない。今のHDDは電源が落ちると自動的にシッピングゾーンに
ヘッドがリトラクトされる。

現実問題として、実使用時においてゴミがとかヘッドが接触とかありえない。
一番可能性があるのが動作時に外部から強い衝撃を受けた時にヘッドがプラッタと接触し、
HDD内にマイクロな粒子が飛散する恐れがある。
 この場合はバッドセクタが発生し、加速度的に増殖して壊れるだろう。


393 名前:login:Penguin mailto:sage [2008/04/12(土) 09:44:05 ID:B8KR3TA1]
スレ開いて自作板かとオモタwwwww

394 名前:login:Penguin mailto:sage [2008/04/12(土) 10:19:10 ID:3VfCSwj0]
ぐうぐる[しっぴんぐぞーん]→うぃきぺでぃあ
| ディスク停止時には磁気ヘッドとプラッタは接触しているが(この際の磁気ヘッド位置をシッピングゾー
| ンと呼ぶ)


395 名前:login:Penguin mailto:sage [2008/04/12(土) 11:29:27 ID:D6Z7h6V2]
全然話についてけないんですけどぉ〜><
平常レベルに落としてよぉ〜><


396 名前:login:Penguin mailto:sage [2008/04/12(土) 11:56:44 ID:ddANuM0+]
>>394
ううん、すまん。俺が分解したIBMのHDDはdiscから完全にヘッドが外れて
ヘッド格納部に格納されるタイプだったんだよ。
このタイプの方がより安全だしね。

スレ違いなのでこのへんで。

397 名前:login:Penguin mailto:sage [2008/04/12(土) 13:21:02 ID:3VfCSwj0]
>>396
それはload/unload(ramp load)方式のドライブで、IBM/HGSTのデスクトップ及び各社のモバイル
向けドライブに採用されています。停止時の安全性と省電力が売りですが、反面load/unload機構は
アームがrampと接触するため耐久性に疑問があること、及びload時にヘッドがプラッタに衝突する
こと、このため結局プラッタ外周部にデータを記録しないランディングゾーンを設けなければならない
ことなど、良いことづくめではありません。

一方停止時にヘッドが着陸するcontact start/stop方式はエンタープライズドライブ及びseagateの
デスクトップに採用されています。古典的な方式なので十分な安全性が確保されていること、
エンタープライズドライブはそもそも回りっ放しが前提なこと、外周の高速な部分が利用できること
などが利点です。反面、モーターが停止するとヘッドは必ず着陸するため、スライダの摩耗や
摩耗による微粒子の飛散などの問題は避け得ません。接触部分は削れにくいようにタフにできて
いますし、プラッタの記録面はゴミが飛んで来てもさらりと受け流すようにコーティングされています
(ふさふさの毛が生えている感じ)。その上に潤滑材が流れていますからまるでマットプレイです。

というようにどちらが一方的に優れているというわけではありませんし、どちらも製品寿命の範囲では
十分な耐久性があるのでもはや信仰の領域です。

……だったのですが、最近load/unload方式に革命的な進歩があり、最新の製品ではついに外周部の
ランディングゾーンがなくなりました。これはついに悲願のヘッドとプラッタの完全非接触が実現したと
いうことであり、load/unloadが一歩前に出たという印象です。


398 名前:login:Penguin mailto:sage [2008/04/12(土) 13:21:22 ID:3VfCSwj0]
>>390
ランディングゾーンはデータ記録部分と違い、停止時にスライダが吸着しないようにわざとデコボコに
作られています。スピンドルモータが完全に停止するまでスライダが魔法的作用で浮いていられれば
よいのですが、現実には回転数が低下した時点で着陸するため、停止するまでガリゴリ削られまくり
です。この状態からモータを回し始めれば、浮揚するまでの間また削られまくりです。

>>387
景気よく動いていたドライブの電源を落とすと急激に冷えて内部の気圧が下がり、あろうことか
外界の汚れた空気を吸い込んでしまいます。もちろんフィルタで異物の侵入を阻むのですが、
世の中完璧には行かないもので。ハードディスクは温度変化が大敵です。

>>378
確かに内周で発生した微粒子は外周に向かって飛散しますが、スライダより遥かに軽い粒子が
吹き飛ばされることなくプラッタに着地するのは極めて稀なことです。また、そういうことが起こっても
困らないように設計されています。ハードディスク30年の歴史の積み重ねはそう短いものでもありません。

というわけでディスクの先頭に重要なデータを置いても困らないぜ? というお話でした。
っていうかバックアップ取っとけ!


399 名前:login:Penguin mailto:sage [2008/04/12(土) 15:40:45 ID:EsTwxU42]
おまえら、たまにはスレタイ読んでくれw


400 名前:login:Penguin mailto:sage [2008/04/12(土) 15:58:09 ID:1E/jpGQt]
コメントアウトされているようです。


401 名前:login:Penguin mailto:sage [2008/04/12(土) 15:59:16 ID:EsTwxU42]
なるほどw



402 名前:login:Penguin mailto:sage [2008/04/12(土) 17:04:40 ID:OZPQRFfQ]
この前、夜中、コンパイルしている時、地震があったんだ。
目が覚めるほどの。

その時、ハードディスクから、
「スチュ、チー、チー、チー」と、異音が…。

俺、「うぉーーー」

けど、なす術もなく、夜中で何もしたくなかったから、放ったらかしで。
翌日、どうしたもんかと思いつつ、
パッケージシステムのファイルダイジェストを確かめるコマンドで
チェックしてみたけど、大丈夫だったみたいだから、気にしないことにした。

思い出したから、書いてみた。

403 名前:login:Penguin mailto:sage [2008/04/20(日) 18:58:46 ID:plVuI/pr]
reiserfsck --rebuild-tree って対象パーティション上に reiserfs らしきものを
見つけるとそれを復元してしまうもんなの?man reiserfsck を見たらそうも読み取れるんだが。

説明下手だけど今起こったことを書く。

/dev/hda9 上に dd で吸い出した別の HD の NTFS パーティションのイメージがある。
まあ、dd if=/dev/hdb1 of=~/ntfs.img をやっただけ。
ntfs.img の中には vmware の Virtual HD の中に reiserfs パーティションがある。

シングルユーザモードで立ち上げて reiserfsck --rebuild-tree /dev/hda9 を
実行したら /dev/hda9 のディレクトリツリーが ntfs.img の中の vmware.vmdk の
reiserfs パーティションの中身に変わってた。

当然ツリーだけが置き換わったんで、ファイルの中身とかはめちゃくちゃなんだけど。
もう何が起こったのかさっぱりわからん。こんなことってありえるもんなのか?

404 名前:login:Penguin mailto:sage [2008/04/20(日) 19:01:13 ID:plVuI/pr]
ちなみに、ntfs.img の中の vmware.vmdk の中は reiserfs に
Debian をインストールしてました。

reiserfsck --rebuild-tree を実行したらこうなってた。

$ df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/hda1 957M 400M 558M 42% /
tmpfs 502M 0 502M 0% /lib/init/rw
udev 10M 108K 9.9M 2% /dev
tmpfs 502M 0 502M 0% /dev/shm
/dev/hda8 1.9G 33M 1.9G 2% /tmp
/dev/hda6 12G 2.7G 8.6G 24% /usr
/dev/hda7 1.9G 1.6G 313M 84% /var
/dev/hda9 205G 79G 127G 39% /home

$ ls /home
bin dev initrd lib opt sbin tmp vmlinuz.old
boot etc initrd.img lost+found proc selinux usr
cdrom home initrd.img.old mnt root srv vmlinuz

405 名前:login:Penguin mailto:sage [2008/04/20(日) 19:37:17 ID:+sFhjnt6]
Exactly(その通りでございます)

406 名前:login:Penguin mailto:sage [2008/04/20(日) 19:47:37 ID:plVuI/pr]
追試してみたら再現したんで自己解決。

結論は、
reiserfs のパーティションを dd 等で吸い出したイメージを
置いてあるパーティションでは reiserfsck --rebuild-tree を
絶対に実行してはいけない。

あらかじめ gzip で圧縮したり、rm で消しておけば大丈夫っぽい。
rm で消した程度だと見つけられるんじゃないかと思ったけど平気だった。

# mkfs.reiserfs /dev/hda9
# mount -t reiserfs /dev/hda9 /mnt
# ls /mnt
#
# dd if=/dev/hda1 of=/mnt/hda1.img
# ls /mnt
hda1.img
# umount /mnt
# mount -t reiserfs /dev/hda9 /mnt
# ls /mnt
bin dev initrd.img media root sys vmlinuz
boot etc initrd.img.old mnt sbin tmp vmlinuz.old
cdrom home lib opt selinux usr
debootstrap initrd lost+found proc srv var
# /mnt/bin/bash
bash: /mnt/bin/bash: cannot execute binary file

407 名前:login:Penguin mailto:sage [2008/04/20(日) 19:50:33 ID:plVuI/pr]
>>405
やっぱそうなのか…。
長々と書いちゃったけど、既出だったらスマソ。

408 名前:login:Penguin mailto:sage [2008/04/20(日) 19:53:51 ID:OEHN1Qvf]
reiserfsのその辺の話は有名かと思ってたけど、そうでも無かったんだ。
どこかまとめページには載ってなかったのかな。

409 名前:login:Penguin mailto:sage [2008/04/20(日) 19:56:00 ID:plVuI/pr]
>>409
作業ログの 8行目と9行目の間に
# reiserfsck --rebuild-tree /dev/hda9
が抜けてた。

大事なデータがなかったからバックアップも取らずに rebuild-tree
したけど、バックアップは取りましょうってことで。

410 名前:login:Penguin mailto:sage [2008/04/20(日) 22:20:04 ID:mzHdbzqB]
>>408
長いことreiserfs使ってるけど知らなかったよ。
人柱乙。つーか、バグレポだしても問題ないレベル?

411 名前:login:Penguin mailto:sage [2008/04/20(日) 22:37:01 ID:XcEPoN04]
Reiser4で直っているそうだよ。
この話はWikipediaに載っている。
en.wikipedia.org/wiki/ReiserFS#fsck



412 名前:login:Penguin mailto:sage [2008/04/29(火) 11:05:23 ID:VXus0Bh+]
Hans Reiser Guilty of First Degree Murder
blog.wired.com/27bstroke6/hans_reiser_trial/#49144716

25年の懲役刑を言い渡されたとあるけど、
アメリカって控訴とかできるの?
もうこれで刑確定なの?

413 名前:login:Penguin mailto:sage [2008/04/29(火) 11:31:54 ID:6biaRDGN]
> defense attorney William DuBois aptly painted a picture of Reiser as
> a misunderstood computer nerd, so inattentive to social cues, and so
> slavishly devoted to logic, that his innocent behavior could be easily
> misinterpreted as evidence of guilt.

陪審員尋問で自ら疑惑を強化してしまったようだが、こんな弁護されても
うれしいかどうか・・・

414 名前:login:Penguin mailto:age [2008/04/30(水) 18:21:02 ID:wqc5ADBb]
xfsについて質問です

大きなパーティションに細かいファイルを大量に書き込むような
使い方をしてるのですが、df または df -iで空き容量、空きinodeが
あるように見えるにもかかわらず ENOSPCで書き込み失敗と
なる現象が発生しています。

調べて見たところ、statvfs()で取得した空き容量と xfs用の ioctl
(XFS_IOC_FSCOUNTS)で取得した空き容量が異なっており、
ioctlで取得した値のほうが正しい(?)と思われる結果になりました。

# ioctl()で取得した情報によると inode不足が原因で書き込みに
# 失敗しているようです。


そこで質問なのですが、xfs_vfsops.cにある xfs_statvfs()と
xfs_fsops.cにある xfs_fs_counts()で空き容量、空きinode数の
算出方法が異なるのは何故でしょうか。

また、正しい空き容量の取得方法についてガイドライン的なものが
あればご教示ください。

# xfsは inodeを動的に確保する仕様だから inode数と空き容量を
# その都度細かく計算する、というロジックに見えるんですが、
# 結果として正しい値が取得できないとしたら本末転倒な気が...
# reiserfsみたいに df -iして inode 0を返すくらいに割り切って
# しまったほうがいいような気もするんですが


415 名前:login:Penguin mailto:sage [2008/04/30(水) 18:25:22 ID:VvZpuE3V]
>>414
大量ってどれくらい?
昔10TBほどに4億ファイルくらい置いたことがあるけど、
問題なかったけどな。
ファイルシステムは壊れてないの?あとバージョンは?

416 名前:login:Penguin mailto:sage [2008/04/30(水) 18:31:36 ID:VvZpuE3V]
すまん。4億じゃなくて1億くらい。

417 名前:414 mailto:sage [2008/04/30(水) 19:24:11 ID:wqc5ADBb]
>>415
容量は約16Tで残り 3Gくらいの状況です。
ファイル数はそんなに多くなくて 900万くらい。
バージョンは kernel-2.6.19.7で確認しました。
環境の都合上、異なる kernelでの確認が困難なため、ほかのkernelでは
試していません。
(kernel-2.6.24.4でもソース見る限りはおなじような…)

xfs_dbの sb表示でも ifreeが 0になっているのに df -iだと
数%しか使用していないことになってます。
また、ためしに loopデバイス上に極小の xfs(100MByte)を作って
ddで限界まで zero埋めしたファイルを作成し、あとはひたすら
touchで細かいファイルを作ったところ df -iで 80残っているのに
書き込みできなくなりました。 (ioctlだと freeinoが 0に見えます)
# この例だと単純に空き容量不足(20kしかない)の可能性もありますが...
# ちなみに kernel-2.6.24.4@amd64です


418 名前:414 mailto:sage [2008/04/30(水) 22:17:46 ID:wqc5ADBb]
>>415
すみません。
1億くらいのファイルを作った xfsパーティションの
フォーマットオプションを覚えていたら教えてください。
あと、1億でやめたのは inode数と空き容量の
どちらかがいっぱいなったからでしょうか。
それとも 1億以上は必要なかったからでしょうか。
(限界まで書き込んだ結果が 1億だったのでしょうか)


419 名前:login:Penguin mailto:sage [2008/05/01(木) 11:06:10 ID:LTFh7Iqg]
>>417
そういう最小再現テストが作れているのなら

TO: linux-fsdevel@vger.kernel.org,
CC: linux-kernel@vger.kernel.org, David Chinner <dgc@sgi.com>

あたりでバグ報告してみたらどうだろうか。
仕様だとしても返事ぐらいはくれると思うので悪い結果にはならんと思うよ


420 名前:login:Penguin mailto:sage [2008/05/01(木) 13:18:14 ID:t9uJxuIJ]
>>419
うーん、やっぱり聞いてみるしかないのかな。
英検3級に落ちるくらいの英語力しかないから
質問しにくくて... orz

あと追加でバグ(?)発見。
100Mくらいの xfsパーティションに 10万個くらいの空ファイル置くと
statvfs()が EOVERFLOWになります。
df -iの値がおかしいから inode数が吹っ飛んでるみたいです。

よわった...

421 名前:414&420 mailto:sage [2008/05/01(木) 13:27:14 ID:t9uJxuIJ]
しまった、420の書き方だと xfs使ってる人が不安になるな。

エラーになるのは 10万個の空ファイルを xfsパーティションの
直下に 「ディレクトリを作らず」に置いた場合です。

普通はこんな使い方しないだろうし、「inodeが吹っ飛ぶ」と
いう表現もファイルシステムが壊れるわけではなく
df -iで表示される inode数がおかしくなるだけです。




422 名前:login:Penguin mailto:sage [2008/05/01(木) 18:45:02 ID:LTFh7Iqg]
>>420
シリコンバレーの8割はノンネイティブなので、やつらはヘタ英語耐性非常に高いよ

423 名前:login:Penguin mailto:sage [2008/05/01(木) 21:57:27 ID:Vkwz20tA]
ReiserFSで有名な米国人プログラマー、殺人罪で有罪の評決

米カリフォルニア州地方裁判所は28日、妻のニーナの殺害容疑で起訴されていた
ハンス・レイザーに対して第一級殺人で有罪の評決を言い渡した。
www.technobahn.com/news/2008/200804301057.html

424 名前:login:Penguin mailto:sage [2008/05/01(木) 22:07:31 ID:ohqQ3Vxz]
ええーーーーー
これネタじゃないの?


425 名前:login:Penguin mailto:sage [2008/05/01(木) 23:07:36 ID:V1OLORy4]
>>424
実はビックリ・・・だったらよかったのに。

426 名前:login:Penguin mailto:sage [2008/05/02(金) 00:22:38 ID:Cb2wHMs4]
スラドに上がってるかと思ったが、上がってないな。


427 名前:login:Penguin mailto:sage [2008/05/02(金) 00:31:12 ID:YW5TTcLV]
スレ違だけど、Reiserがほんとに殺人犯かは別として、
アメリカの裁判って全然正義じゃないと思う。
マイケルジャクソンの時がいい例。

428 名前:login:Penguin mailto:sage [2008/05/02(金) 00:36:39 ID:Cb2wHMs4]
しかし、状況から見れば限りなく黒だよなぁ。


429 名前:login:Penguin mailto:sage [2008/05/02(金) 00:40:00 ID:dkUYFm2d]
>>426
あがってるよ
slashdot.jp/linux/article.pl?sid=08/04/29/2111236
yro.slashdot.org/article.pl?sid=08/04/28/2243232

430 名前:login:Penguin mailto:sage [2008/05/02(金) 04:25:06 ID:PQoOJPga]
>>427
検挙すらまぬかれる日本よりマシw

431 名前:login:Penguin mailto:sage [2008/05/03(土) 21:54:30 ID:+ggzsGlh]
delugeでスペースを確保する時フルアローケーションより
コンパクトアローションの方が読み込みが速いんだけど
reiserfsの場合断辺化は多い方が読み込みが速いもんなの?



432 名前:login:Penguin mailto:sage [2008/05/03(土) 22:40:42 ID:A1deGZTu]
ベンチマークってどのソフトが有名なの?
新しいhdd買ってちょい古めのhdd空いたから色々fsテストしてみたいんだがさっぱり。

433 名前:login:Penguin mailto:sage [2008/05/03(土) 22:43:37 ID:fC71zTdk]
Iozone






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

前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