/**ファイルシステム� ..
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多くない気がするがどうなんだ?
357:login:Penguin
08/04/09 13:29:32 P7VWxNnr
ext4でデフラグがようやく使えるようになると聞いたのですが。まだ未実装だっけか。
しないとパフォーマンス悪いってのはやっぱ、
linuxでは「必要ない」、ではなく「できない」の間違いだったってことですよね。
358:login:Penguin
08/04/09 13:42:10 KQOYg6Em
今時のHDDにデフラグって必要ないんじゃないの？
359:login:Penguin
08/04/09 13:48:54 XsC9hakW
ext4の本流にはまだmergeされてない。
が、NECの人が頑張っている流れで実装はある。ext3用のも。
ext2/3ではデフラグが必要ないというより、開発当時の環境では、
デフラグのコストが性能の低下より大きかった、という話じゃないかな。
最近のドライブの大容量化や高速化でそうも言っていられなくなっただけ。
360:login:Penguin
08/04/09 16:46:40 bJQ+WBXU
どんなに断片化に強かろうが、使っていれば少しづつ断片化していく訳だが
サーバ市場で普及が進んだおかげでLinuxを長期運用する例が増え
比例して断片化の進み具合やその影響も馬鹿にならなくなってきて
それを解消したがる顧客の声もそこそこの規模になり
更にext4は状況によってext2/3より断片化が発生しやすくなってしまった。
このような時代の流れによりNEC開発陣はデフラグツール開発の大義名分をゲット。
金庫番との死闘と末、開発費を捻出させることに成功したのであった。やったね。
こうですか？わかりません＞＜
361:login:Penguin
08/04/09 17:00:20 KQOYg6Em
HDD側のキャシュ増やした方がいいような？
362:login:Penguin
08/04/09 18:30:34 LVCZieeg
>>360
発想が昭和の人って素敵って感じだね。
363:login:Penguin
08/04/09 18:46:45 5v+cawCi
俺デフラグずっと眺めてるの好きなのでぜひグラフィカルなUIを用意してもらいたい。
364:login:Penguin
08/04/09 23:04:39 HmwSCQL2
>>363
win98のころのブロックが移動して色変わってくの好きだったのに2ｋぐらいから
ただの棒になって色変わるだけになってつまんなくなったな
365:login:Penguin
08/04/09 23:44:17 OcdXE9xM
ブロックのやつはそれこそDOSな時代からだよ。
あれは趣があった。
366:login:Penguin
08/04/09 23:57:02 MHOGD1vi
乗せたらダマス 魔法の絨毯 騙され続けて四半世紀だな
デフラグってプラセボつーか依存だよね。3日開けずにやっている香具師いる。
367:login:Penguin
08/04/10 00:23:32 A4V/r+Uq
デフラグを高速化するために最新のHDDを買い、
HDDがフラグメントしないようにデータをあまり書かない。
そんな時代も俺にはありました・・・
368:login:Penguin
08/04/10 00:40:21 sVUazSs4
神経質な奴ほどデフラグ中毒になりやすい。
デフラグ中の画面を延々見てる奴。
洗濯中にグルグル回ってるのを延々見てる奴。
両者は似ているようで少し層が違う。
369:login:Penguin
08/04/10 00:53:04 M4lYQAYA
defrag中毒のヤシはLFS系のfsつかえばいいのに
370:login:Penguin
08/04/10 01:30:53 NY5kJFee
デフラグの画面は人間の生産性を驚異的に落とす最悪のGUIなので
ライフハック（笑）的には真っ先に削除されるべき
371:login:Penguin
08/04/10 01:49:42 gvIBE6hj
LFSとか言われてもな
372:login:Penguin
08/04/10 04:06:43 Gfyr/fVJ
>>368
洗濯機のグルグルは気持ちが落ち着く
デフラグはイライラする・・真逆
373:login:Penguin
08/04/10 10:21:47 REpR0D1a
なんか洗濯機を眺めながら一人で酒を飲んでるって芸人がいなかったっけ?
374:login:Penguin
08/04/10 10:49:40 H34Gbw9O
麒麟の非公園生活者の方（川島）だったな。
ちなみに今は洗濯機そっちのけで眞鍋かをりに乗っかってるとか。
375:login:Penguin
08/04/10 15:59:42 AsPLT2gw
>>350
C2D対応のソースまだぁ？
376:login:Penguin
08/04/10 18:46:32 4oJRCPdx
デフラグはHFS+のように、
自動デフラグ解消機能をFSに埋め込むって案はないの？
良くアクセスするファイルを、HDDの先頭に移動して高速化するって案は？
377:login:Penguin
08/04/10 19:46:00 g/S3sRn9
vxfsﾏﾝｾｰ
378:login:Penguin
08/04/11 02:25:29 xdk7g0sU
>>376
＞良くアクセスするファイルを、HDDの先頭に移動して高速化するって案は？
そういう製品もあるよ
ただHDDの先頭は汚染されやすい
（プラッタ上のゴミ等は遠心力で外周に向かいやすい）
ってことを考えると労力の割には微妙だなあと俺は思う
379:login:Penguin
08/04/11 02:33:15 2V7teuhD
良くアクセスするファイルってほとんどの期間osのキャッシュ上にあるんじゃないかな?
ブート時の立ち上がりアクセスを連続化とかそういうのはlinuxじゃ難しそうだし、思想的に好かれなそう。
380:login:Penguin
08/04/11 10:18:34 gfqUbArl
>（プラッタ上のゴミ等は遠心力で外周に向かいやすい）
どんなファイルシステムだよ、と思ったら物理メディアの話か…
381:login:Penguin
08/04/11 11:50:29 NtcJovKM
HDDの中はクリーンでしょ・・・
382:login:Penguin
08/04/11 12:54:43 xdk7g0sU
>>381
プラッタとヘッダが接触する→破片が飛ぶ
あと誤解されがちだがHDDは密閉されていないので
埃等の進入も無いわけではない
383:login:Penguin
08/04/11 14:27:02 NtcJovKM
>>382
ヘッドが接触した時点でバッドセクタ発生で使用中止するでしょ。
気圧調整のために穴が空いているけど、フィルタシールされているから、
埃は外部から侵入しないよ。
384:login:Penguin
08/04/11 15:04:27 xdk7g0sU
フィルタがあるから進入しないというのは暴論だな
385:login:Penguin
08/04/11 15:32:21 EtOBVwEL
>>382
昔のHDDと違って今のはヘッドは接触してないでしょ。
といってもμとかそれ以下のオーダーで離れてるだけだけど。
386:login:Penguin
08/04/11 17:24:52 510mZMoh
しょっちゅうカコンカコンいってますが何か？
387:login:Penguin
08/04/11 20:26:13 2qIbW6EC
破片云々や遠心力云々、
ヘッドの接触を前提に語ってる奴の言葉など、何一つ信用できない。
ちなみに、ヘッドの浮く高さはよく煙草の煙より狭いと言われるが
だからこそ、そのサイズのゴミさえ侵入しないように作られている。
388:login:Penguin
08/04/11 20:31:20 2V7teuhD
てかもうSSDになるんだから、ランダムリードのアクセスはかなり無視できるだろう。
書き込みの遅さと読み込みの速さをどううまくカバーできるかとかやってるのかな?
なんとなくだが追記型のが相性良さそう。
389:login:Penguin
08/04/11 20:34:54 9r4cpd5H
よくわからんが
コンタクト・スタート・ストップとかで接触するんじゃないの。
390:login:Penguin
08/04/12 01:21:44 zKuK+tHg
非動作時等に接触するのは事実だが
そこが回転しているかどうか。
動いていない部分にヘッドが接触して破片がとぶって、
どれほどの衝撃でヘッドが着地するのかと。
391:login:Penguin
08/04/12 02:04:05 UJnKfLiT
>>388
現状ではランダムリードが遅いSSDなんて腐るほどある。
今のHDDでMemoryいっぱい積んだ方が安くて速い。
392:login:Penguin
08/04/12 03:55:16 ddANuM0+
>>390
>非動作時等に接触するのは事実だが
接触しない。今のHDDは電源が落ちると自動的にシッピングゾーンに
ヘッドがリトラクトされる。
現実問題として、実使用時においてゴミがとかヘッドが接触とかありえない。
一番可能性があるのが動作時に外部から強い衝撃を受けた時にヘッドがプラッタと接触し、
HDD内にマイクロな粒子が飛散する恐れがある。
この場合はバッドセクタが発生し、加速度的に増殖して壊れるだろう。
393:login:Penguin
08/04/12 09:44:05 B8KR3TA1
スレ開いて自作板かとオモタwwwww
394:login:Penguin
08/04/12 10:19:10 3VfCSwj0
ぐうぐる[しっぴんぐぞーん]→うぃきぺでぃあ
| ディスク停止時には磁気ヘッドとプラッタは接触しているが（この際の磁気ヘッド位置をシッピングゾー
| ンと呼ぶ）
395:login:Penguin
08/04/12 11:29:27 D6Z7h6V2
全然話についてけないんですけどぉ～＞＜
平常レベルに落としてよぉ～＞＜
396:login:Penguin
08/04/12 11:56:44 ddANuM0+
>>394
ううん、すまん。俺が分解したIBMのHDDはdiscから完全にヘッドが外れて
ヘッド格納部に格納されるタイプだったんだよ。
このタイプの方がより安全だしね。
スレ違いなのでこのへんで。
397:login:Penguin
08/04/12 13:21:02 3VfCSwj0
>>396
それはload/unload(ramp load)方式のドライブで、IBM/HGSTのデスクトップ及び各社のモバイル
向けドライブに採用されています。停止時の安全性と省電力が売りですが、反面load/unload機構は
アームがrampと接触するため耐久性に疑問があること、及びload時にヘッドがプラッタに衝突する
こと、このため結局プラッタ外周部にデータを記録しないランディングゾーンを設けなければならない
ことなど、良いことづくめではありません。
一方停止時にヘッドが着陸するcontact start/stop方式はエンタープライズドライブ及びseagateの
デスクトップに採用されています。古典的な方式なので十分な安全性が確保されていること、
エンタープライズドライブはそもそも回りっ放しが前提なこと、外周の高速な部分が利用できること
などが利点です。反面、モーターが停止するとヘッドは必ず着陸するため、スライダの摩耗や
摩耗による微粒子の飛散などの問題は避け得ません。接触部分は削れにくいようにタフにできて
いますし、プラッタの記録面はゴミが飛んで来てもさらりと受け流すようにコーティングされています
(ふさふさの毛が生えている感じ)。その上に潤滑材が流れていますからまるでマットプレイです。
というようにどちらが一方的に優れているというわけではありませんし、どちらも製品寿命の範囲では
十分な耐久性があるのでもはや信仰の領域です。
……だったのですが、最近load/unload方式に革命的な進歩があり、最新の製品ではついに外周部の
ランディングゾーンがなくなりました。これはついに悲願のヘッドとプラッタの完全非接触が実現したと
いうことであり、load/unloadが一歩前に出たという印象です。
398:login:Penguin
08/04/12 13:21:22 3VfCSwj0
>>390
ランディングゾーンはデータ記録部分と違い、停止時にスライダが吸着しないようにわざとデコボコに
作られています。スピンドルモータが完全に停止するまでスライダが魔法的作用で浮いていられれば
よいのですが、現実には回転数が低下した時点で着陸するため、停止するまでガリゴリ削られまくり
です。この状態からモータを回し始めれば、浮揚するまでの間また削られまくりです。
>>387
景気よく動いていたドライブの電源を落とすと急激に冷えて内部の気圧が下がり、あろうことか
外界の汚れた空気を吸い込んでしまいます。もちろんフィルタで異物の侵入を阻むのですが、
世の中完璧には行かないもので。ハードディスクは温度変化が大敵です。
>>378
確かに内周で発生した微粒子は外周に向かって飛散しますが、スライダより遥かに軽い粒子が
吹き飛ばされることなくプラッタに着地するのは極めて稀なことです。また、そういうことが起こっても
困らないように設計されています。ハードディスク30年の歴史の積み重ねはそう短いものでもありません。
というわけでディスクの先頭に重要なデータを置いても困らないぜ? というお話でした。
っていうかバックアップ取っとけ!
399:login:Penguin
08/04/12 15:40:45 EsTwxU42
おまえら、たまにはスレタイ読んでくれw
400:login:Penguin
08/04/12 15:58:09 1E/jpGQt
コメントアウトされているようです。
401:login:Penguin
08/04/12 15:59:16 EsTwxU42
なるほどw
402:login:Penguin
08/04/12 17:04:40 OZPQRFfQ
この前、夜中、コンパイルしている時、地震があったんだ。
目が覚めるほどの。
その時、ハードディスクから、
「スチュ、チー、チー、チー」と、異音が…。
俺、「うぉーーー」
けど、なす術もなく、夜中で何もしたくなかったから、放ったらかしで。
翌日、どうしたもんかと思いつつ、
パッケージシステムのファイルダイジェストを確かめるコマンドで
チェックしてみたけど、大丈夫だったみたいだから、気にしないことにした。
思い出したから、書いてみた。
403:login:Penguin
08/04/20 18:58:46 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
08/04/20 19:01:13 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
08/04/20 19:37:17 +sFhjnt6
Exactly（その通りでございます）
406:login:Penguin
08/04/20 19:47:37 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
08/04/20 19:50:33 plVuI/pr
>>405
やっぱそうなのか…。
長々と書いちゃったけど、既出だったらスマソ。
408:login:Penguin
08/04/20 19:53:51 OEHN1Qvf
reiserfsのその辺の話は有名かと思ってたけど、そうでも無かったんだ。
どこかまとめページには載ってなかったのかな。
409:login:Penguin
08/04/20 19:56:00 plVuI/pr
>>409
作業ログの 8行目と9行目の間に
# reiserfsck --rebuild-tree /dev/hda9
が抜けてた。
大事なデータがなかったからバックアップも取らずに rebuild-tree
したけど、バックアップは取りましょうってことで。
410:login:Penguin
08/04/20 22:20:04 mzHdbzqB
>>408
長いことreiserfs使ってるけど知らなかったよ。
人柱乙。つーか、バグレポだしても問題ないレベル？
411:login:Penguin
08/04/20 22:37:01 XcEPoN04
Reiser4で直っているそうだよ。
この話はWikipediaに載っている。
URLﾘﾝｸ(en.wikipedia.org)
412:login:Penguin
08/04/29 11:05:23 VXus0Bh+
Hans Reiser Guilty of First Degree Murder
URLﾘﾝｸ(blog.wired.com)
25年の懲役刑を言い渡されたとあるけど、
アメリカって控訴とかできるの？
もうこれで刑確定なの？
413:login:Penguin
08/04/29 11:31:54 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
08/04/30 18:21:02 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
08/04/30 18:25:22 VvZpuE3V
>>414
大量ってどれくらい？
昔10TBほどに4億ファイルくらい置いたことがあるけど、
問題なかったけどな。
ファイルシステムは壊れてないの？あとバージョンは？
416:login:Penguin
08/04/30 18:31:36 VvZpuE3V
すまん。４億じゃなくて１億くらい。
417:414
08/04/30 19:24:11 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
08/04/30 22:17:46 wqc5ADBb
>>415
すみません。
1億くらいのファイルを作った xfsパーティションの
フォーマットオプションを覚えていたら教えてください。
あと、1億でやめたのは inode数と空き容量の
どちらかがいっぱいなったからでしょうか。
それとも 1億以上は必要なかったからでしょうか。
(限界まで書き込んだ結果が 1億だったのでしょうか)
419:login:Penguin
08/05/01 11:06:10 LTFh7Iqg
>>417
そういう最小再現テストが作れているのなら
TO: linux-fsdevel@vger.kernel.org,
CC: linux-kernel@vger.kernel.org, David Chinner <dgc@sgi.com>
あたりでバグ報告してみたらどうだろうか。
仕様だとしても返事ぐらいはくれると思うので悪い結果にはならんと思うよ
420:login:Penguin
08/05/01 13:18:14 t9uJxuIJ
>>419
うーん、やっぱり聞いてみるしかないのかな。
英検3級に落ちるくらいの英語力しかないから
質問しにくくて... orz
あと追加でバグ(?)発見。
100Mくらいの xfsパーティションに 10万個くらいの空ファイル置くと
statvfs()が EOVERFLOWになります。
df -iの値がおかしいから inode数が吹っ飛んでるみたいです。
よわった...
421:414&420
08/05/01 13:27:14 t9uJxuIJ
しまった、420の書き方だと xfs使ってる人が不安になるな。
エラーになるのは 10万個の空ファイルを xfsパーティションの
直下に 「ディレクトリを作らず」に置いた場合です。
普通はこんな使い方しないだろうし、「inodeが吹っ飛ぶ」と
いう表現もファイルシステムが壊れるわけではなく
df -iで表示される inode数がおかしくなるだけです。
422:login:Penguin
08/05/01 18:45:02 LTFh7Iqg
>>420
シリコンバレーの８割はノンネイティブなので、やつらはヘタ英語耐性非常に高いよ
423:login:Penguin
08/05/01 21:57:27 Vkwz20tA
ReiserFSで有名な米国人プログラマー、殺人罪で有罪の評決
米カリフォルニア州地方裁判所は28日、妻のニーナの殺害容疑で起訴されていた
ハンス・レイザーに対して第一級殺人で有罪の評決を言い渡した。
URLﾘﾝｸ(www.technobahn.com)
424:login:Penguin
08/05/01 22:07:31 ohqQ3Vxz
ええーーーーー
これネタじゃないの？
425:login:Penguin
08/05/01 23:07:36 V1OLORy4
>>424
実はビックリ・・・だったらよかったのに。
426:login:Penguin
08/05/02 00:22:38 Cb2wHMs4
スラドに上がってるかと思ったが、上がってないな。
427:login:Penguin
08/05/02 00:31:12 YW5TTcLV
スレ違だけど、Reiserがほんとに殺人犯かは別として、
アメリカの裁判って全然正義じゃないと思う。
マイケルジャクソンの時がいい例。
428:login:Penguin
08/05/02 00:36:39 Cb2wHMs4
しかし、状況から見れば限りなく黒だよなぁ。
429:login:Penguin
08/05/02 00:40:00 dkUYFm2d
>>426
あがってるよ
URLﾘﾝｸ(slashdot.jp)
URLﾘﾝｸ(yro.slashdot.org)
430:login:Penguin
08/05/02 04:25:06 PQoOJPga
>>427
検挙すらまぬかれる日本よりマシｗ
431:login:Penguin
08/05/03 21:54:30 +ggzsGlh
delugeでスペースを確保する時フルアローケーションより
コンパクトアローションの方が読み込みが速いんだけど
reiserfsの場合断辺化は多い方が読み込みが速いもんなの？
432:login:Penguin
08/05/03 22:40:42 A1deGZTu
ベンチマークってどのソフトが有名なの?
新しいhdd買ってちょい古めのhdd空いたから色々fsテストしてみたいんだがさっぱり。
433:login:Penguin
08/05/03 22:43:37 fC71zTdk
Iozone
434:login:Penguin
08/05/03 22:56:40 A1deGZTu
ふむ、それでちょっとやってみるわ。
435:login:Penguin
08/05/09 14:48:12 9yigZLhc
>>423
ヴォースゲー
そういやファイルシステム屋ってイッちゃってる人多いよな・・・
436:login:Penguin
08/05/09 22:36:24 XBsQ5sGw
>435
他の例も教えてくれw
437:login:Penguin
08/05/10 00:23:32 avOohQIM
XFSでディスク追加しつつgrowfsで増やしてたらagcount=48とかになった。
さすがに大杉て性能低下してるっぽい。READが圧倒的に多い用途だから、
探索コスト重視でagcount=1とかが良さそうなんだけど、
xfs_fsr使えなくなるみたいだし……いくつぐらいがいい？
438:login:Penguin
08/05/10 00:27:54 IAFdsD6t
新しいxfsprogsだとagcountのデフォルトが半分くらいに減らされてて
数GB～100GBのファイルシステムで全部agcount=4になってる
439:login:Penguin
08/05/10 02:44:21 avOohQIM
うちのxfsprogsだとデフォルトagcount=16っぽい
xfs_fsrが動く範囲で小さめの値をいろいろ試してみます。ありがとー
440:login:Penguin
08/05/11 22:53:41 wi9PMfW6
ext4にしちゃったら、ext2fsdとかext2ifs使ってWindowsから読めなくなるんですか？
ていうか他のファイルシステムもWindowsから使えるようにしてほしいです。
441:login:Penguin
08/05/11 22:57:39 uhEE1HnM
>>440
colinux + samba使えばいいんじゃね?
442:login:Penguin
08/05/12 17:33:47 XUuf2cul
思うのだが、Linuxのファイルシステムの多くがWindowsから読めないのはLinuxのせいにされるが、
あるLinuxマシンにたまたまfat32とかntfsのドライバが入っていなくてもそれはLinuxのせいにされるよな。
（以前は「書き込めないのはLinuxのせい」みたいな感じだったし）
損な役回りだなww
443:login:Penguin
08/05/12 18:19:47 tGJxYdMx
・後発のソフトは常に損な役回り
・Windowsに固執すると永遠に幸せになれない
444:login:Penguin
08/05/12 19:08:17 e+U0PNje
>>442
LinuxのfsがWindowsから読めないのはWindowsのせいだろ。
ext3とreiserfsが読めるようになればWindows買ってもいいかなと思う。
445:login:Penguin
08/05/12 20:34:03 VZVqJBQc
>>444
Windowsにext3が実装されたら、LinuxのVFSが…
446:login:Penguin
08/05/12 21:16:18 jZeC6gUE
ext3は前述ので読める
reiserfsは読み取り専用のドライバだけあったような
447:login:Penguin
08/05/12 21:32:25 ZIjl6UnX
つ samba
448:login:Penguin
08/05/12 21:33:40 Vi3d3nrS
LinuxDrive for Windowsってソフトが補論から昔出てたな
使ったことないから分からんけど
449:login:Penguin
08/05/13 14:17:27 B3PAG86a
>>444
おまい、かっこいいなｌ。
450:login:Penguin
08/05/15 04:35:46 g09JXgWn
Parallel Optimized Host Message Exchange Layered File System
URLﾘﾝｸ(kerneltrap.org)
4. POHMELFS vs NFS benchmark.
URLﾘﾝｸ(tservice.net.ru)
URLﾘﾝｸ(tservice.net.ru)
URLﾘﾝｸ(tservice.net.ru)
451:login:Penguin
08/05/18 22:06:34 n0FAfdxt
ReiserFSって本当に終了しちゃうの？
452:login:Penguin
08/05/18 23:41:42 8tQ4zrTk
終了しちゃうとしても、逮捕されちゃったんじゃ、しゃーないでしょ。
ところで、終了するってソースは？
453:login:Penguin
08/05/18 23:53:42 Kon4k1Vh
３はすでに機能的には旧世代のものだし（メンテはされるだろうが）、
４は周知のとおり、マージすらされてないから放置。
454:login:Penguin
08/05/19 00:01:29 ZzkuNU9W
3は別に旧世代じゃないし、4は3以下。
455:login:Penguin
08/05/19 00:08:09 EilDrdA2
>>454
reiser4はかなり前から-mmにマージされているがバグ報告とか見たことないので、誰も使ってないんじゃないか。と疑っている
456:login:Penguin
08/05/19 03:34:44 q1NfHESk
>>451
16TB越えのパーティションサイズが普通に使われるようになったら終了だろうね。
近い未来だろうけれど、それまでは主力のファイルシステムとして幅を利かせ続ける。
あと5年くらいか。
457:login:Penguin
08/05/19 08:09:47 094JTCHh
え、今Linuxの主力FSって、何があげられるんですか？
458:login:Penguin
08/05/19 08:28:05 /Waga8Mz
主力と呼べそうなのはext3しかないだろ
間違ってもreiserfsじゃない
459:login:Penguin
08/05/19 16:47:30 QIATkluX
普通にext3だね
Wikipedia項目ﾘﾝｸ
期待はされたんだけどなぁ＞reiserfs
460:login:Penguin
08/05/19 18:05:47 x2MlYmix
普通にreiserfsだろ。ext3はおそすぐる。
461:login:Penguin
08/05/19 19:12:33 kGzpiLaP
>>455
一人だけreiser4使ってる人しっている。
>>460
今更reiserfsもないと思う。
suseも手を引いちゃったし。
462:login:Penguin
08/05/19 19:41:18 48/pRU4B
URLﾘﾝｸ(blogs.sun.com)
で、ZFSが載ってくれば、皆忘れていくさ・・・
463:login:Penguin
08/05/19 19:46:39 H0npQQv0
はいはいZFS最強ZFS最強
464:login:Penguin
08/05/19 21:15:56 ZzkuNU9W
ZFSは期待してたが遅すぎ。早く目を覚ますべき。
reiserfsは悪くない選択肢。マウントが遅いのに目を瞑れば。
ext3は無難。先も明るい。
465:login:Penguin
08/05/19 21:29:49 KfYOlogJ
無言でJFSを使い続ける。
466:login:Penguin
08/05/19 21:36:16 dpCUD8Xx
問題はライセンスなんだよなあ。
fuse経由では使いものにならないし。
あと結構ZFSって要求スペック高くね？
このへんは時間が解決してくれるかな(期待
467:login:Penguin
08/05/19 21:36:38 civQAuJU
OracleがZFSもどき作ってたな。
OCFSともども全く注目されてないけどｗ
468:login:Penguin
08/05/19 21:38:48 q1NfHESk
結局現状では、高速・高利用効率で実績も充分にあるreiserfsが選ばれやすいんだよね。
大きなデメリットもないし。
特に理由がなければreiserfsを選ぶのが無難かつ最適なケースが多い。
469:login:Penguin
08/05/19 22:14:36 qS/NQTMT
みなさん、今一度lost+foundの中を確認してください。
Reiserの嫁さんが居るかもしれません。
470:login:Penguin
08/05/19 22:40:34 q1NfHESk
うちのreiserfsにはlost+foundが無いんだけど。
Hansが証拠隠滅したのかな？
471:login:Penguin
08/05/19 22:53:02 ZzkuNU9W
俺のもない。Hansが捕まる前はあったのに…。
472:login:Penguin
08/05/19 23:19:48 Nka1lmTo
dumpで埋められたのかも
473:login:Penguin
08/05/19 23:25:14 X2D+O09h
で、無言の多数派はXFSと。
実際にはext系で大抵の用途は充分だしなぁ
474:login:Penguin
08/05/19 23:26:49 v0zMl1ni
500とか1GBなどの動画ファイルの格納先としては、やっぱりXFSが最適ですか？
475:login:Penguin
08/05/19 23:43:54 EilDrdA2
最近動画専用ファイルシステムが投稿されてたね。そういえば
476:login:Penguin
08/05/20 01:02:16 aN/Be4xB
>>475
kwsk
477:login:Penguin
08/05/20 01:16:16 pV7pmg2U
Windowsと共有用途とか case insensitive な file system だとJFSの一択になるな
vfatに保存するほどマゾじゃないし、NTFSは case sensitiveだし
478:login:Penguin
08/05/20 01:34:16 zYwOwEvw
今度hddを足すことがあったら、xfsとjfsを試してみるんだ。
いろんなファイルシステムが混在してるぜ。
winを使っていたころには考えられなかった楽しみだな。
479:login:Penguin
08/05/20 01:47:25 5p0mfIHX
JFSってwindowsから使えるの？
480:login:Penguin
08/05/20 02:15:39 D0FaA2M8
>>477
XFSにcase insentiveサポートを追加するパッチが投稿されてたけど、i18nかじったことあるやつが議論に加わると「caseってなにさ？」から始まるので話がまとまらない。
困ったものだ。
ところで、NTFSすらcase sensitiveなのに、なんでcase insensitiveが必要になるんだい？
481:login:Penguin
08/05/20 02:58:02 4paPLLL+
ここ(>>450以降あたり)でいってるreiserfsって3のこと？
482:login:Penguin
08/05/20 03:12:45 hx5NkZpC
yes
483:login:Penguin
08/05/20 05:35:26 CGOJLBT4
insensitiveなんてSamba側でやらせるよ
484:480
08/05/20 05:46:52 D0FaA2M8
>>483
たぶんそれが正解。
世の中で求められているのはバグも含めてWindowsと完全互換な挙動であって「正しい」 case insensitive ではないと思う
485:login:Penguin
08/05/20 15:52:17 7zhBv2ee
少し前に知ったんだけど
WindowsのNT系だと
"A"と"a"を同一視するのは当然だけど
"Ａ"と"ａ"も同一視するんだぜ。
(9xだと"Ａ"と"ａ"は別扱い)
NTFSで区別出来るかは知らないけど、FATだと当然区別できて
"Ａ"と"ａ"が両方あるディレクトリをNT系で読むと片方しか操作できないらしい。
たぶんディレクトリエントリの並び順とかによるんだろうが。
試してないが、samba上に"Ａ.txt"と"ａ.txt"を置いても
操作できるのは片方なんじゃないかね。
486:login:Penguin
08/05/20 15:57:55 Y/B6ib8Y
キリル文字とかギリシア文字がどうなるのかも気になるなwww
487:login:Penguin
08/05/20 17:05:38 R7fVkyDq
>>485
そりゃNT系が、っていうより、explorer とかの特定のアプリが、ってことなんじゃ？
ファイルシステムの問題じゃないような。
488:login:Penguin
08/05/20 17:13:34 1uNl2xi7
Explorer て変なことするよな。ドットで始まったり終わるファイル作れないし。
まぁ拡張子非表示にしていると見えないとかいう理由なんだろうけど。
489:login:Penguin
08/05/20 17:46:12 Aur5JlSq
>>485
ユニコードだからじゃね？
490:login:Penguin
08/05/20 17:57:39 z2v1aIzv
>>468
ext系、xfsなどと比べれば実績は少ない方なんじゃまいか
491:login:Penguin
08/05/20 22:24:57 pV7pmg2U
>>287
実はそれが問題でね、ちょっと古い(といっても大半のアプリが使用してる)WINAPIから
だとcase 違いのファイルが扱えない。むしろ積極的に困った動作をしてくれる。
NTFSは case sensitive だから、そういうファイルは作れる。
だから本末転倒だが、file system のほうで case insensitive にするほうが、
Windows OSを安全に使用できるという訳。
492:login:Penguin
08/05/20 22:45:22 Aur5JlSq
>>488
.で終わるファイルはcmd.exeからでも作れない。
493:login:Penguin
08/05/20 23:15:06 eaiw47c3
>>490
linux上での実績
ext3 > reiserfs >>> xfs
速度
reiserfs > xfs >>> ext3
ディスクの利用効率
xfs > reiserfs > ext3
494:login:Penguin
08/05/20 23:29:35 7zhBv2ee
>>487
特定のアプリの問題じゃない。
普通のAPI、例えばMoveFileが失敗するし
CreateFileでopen出来るのも片方だけ。
何が問題なのかと言うと、両方のファイルがあるディレクトリでは
一覧を取ると両方が見えるのに、操作(例えばopen)しようとすると片方のみが対象となるので
意図しないファイルを触ってしまう可能性があるから。
495:login:Penguin
08/05/20 23:33:30 7zhBv2ee
あ、もちろん、ファイルシステムの問題じゃないよ。
OSの扱いの問題なだけ。
わざわざ持ち出したのは、上のほうで「Windows互換」という話が出たから。
496:login:Penguin
08/05/21 00:36:25 J4TqOFWl
>>493
linux上での実績
ext3 > reiserfs >>> xfs
↑これほんと？
xfsは最古のジャーナリングFSって言われるし、SGIのIRIXから使われ始めたでしょ
reiserfsなんて色々もめて結局マージされたのって2000年以降じゃん
497:login:Penguin
08/05/21 00:44:54 CQPnoXR/
>>496
そりゃファイルシステムとしての実績なら
xfs>>>ext3>reiserfs
だろうけど、「Linuxでの」実績だし。
個人的には ext3>reiserfs>=xfs 位だと思う。あの xfs が割とすんなり
マージされたのに reiserfs がマージされないのはなぜだとか思ってたけど。
498:login:Penguin
08/05/21 08:10:15 5JD2ckh4
>>496
ヒント: suse
499:login:Penguin
08/05/21 14:17:21 g1UfGfjU
SUSEはもうreiserfsを見捨てたよ
URLﾘﾝｸ(opentechpress.jp)
500:login:Penguin
08/05/21 14:26:56 Y7uwz6Fw
今さら何を？
501:login:Penguin
08/05/21 14:37:05 J4TqOFWl
＞reiserfs がマージされないのはなぜだとか思ってたけど。
ハンスの性格的問題も多分に・・・（ゴホッゴホッ
502:login:Penguin
08/05/21 14:44:44 Ci3au8LA
はアァァァんす
503:login:Penguin
08/05/21 20:06:01 gLL5ZX1c
>>492
copy nul \\?\%CD%\nullpo.
504:login:Penguin
08/05/21 20:06:22 YO2Ssk3x
>>499
実績の話をしてるんだから、今まで採用されていた実績が議論の対象で、
見捨てられたことは関係ないだろう。
505:login:Penguin
08/05/21 20:18:17 /Z1sqvHT
reiserfsの流れをぶった切って質問
今、Sambaメインのファイルサーバ建てるとして、FSは何がお勧めなの？
2Tくらいで50MB～2GBくらいまで、さまざまなファイルサイズを扱うとして。
506:login:Penguin
08/05/21 20:27:17 5JD2ckh4
reiserfs
507:login:Penguin
08/05/21 20:48:10 b+9jifIY
>>503
ガッ
508:login:Penguin
08/05/21 21:19:28 Ci3au8LA
>>503
残念。
それだと、作られるファイルは、nullpoであって、nullpo.ではない。
509:login:Penguin
08/05/21 21:48:42 pWHvlEE4
>>505
マヂレスするとWin 2003 serverつかってNTFS
510:login:Penguin
08/05/21 21:56:42 Aej85mCI
>>509
ここはLinux板だというに。
Linux以外でいいのなら、NetAppのDataONTAP上のWAFLを使うだろ。
511:login:Penguin
08/05/21 23:55:34 /Z1sqvHT
レスさんくす。
Linux板ではSamba使ったファイルサーバのFSのお勧めが無い事を理解した。
512:login:Penguin
08/05/22 00:08:55 nmRfdow3
というか、fs云々以前にCIFS/SMBの実装ではレファレンス実装のWinのほうがsambaよりも圧倒的にいいから。
CIFS/SMBが主用途ならLinuxを使う意味はない。
NetAppはNFSではいいけど、CIFS/SMBではどうなのか知らん。
513:login:Penguin
08/05/22 00:24:47 oyxtcAu/
>>512
いや、もうわかったから。
質問する時に構成とか物理的な事情とか全部込みで記載して納得しないと
質問の内容に沿った回答はしたくないって事かい。
よかれと思って言ってるんだろうけど、そういうのはありがた迷惑だよ。
514:login:Penguin
08/05/22 00:26:01 RHUMboQ3
>>511
つか、2TBくらいの小規模ストレージならext3で普通にいいからお勧め。
一番利用者が多く一番テストされているので一番安定している。
515:login:Penguin
08/05/22 00:50:35 nmRfdow3
>>513
お前が非常識かつ恥垢臭の漂う生ける悪臭公害なのは理解できた。
頭のほうは手のつけようがないけど、包茎は治る障害だぞ。さっさと手術しろ。
516:login:Penguin
08/05/22 01:05:26 ygnClFlx
レス番号間違えてるんじゃね？文脈からして。
517:login:Penguin
08/05/22 01:09:53 BcXpovCg
>>513
勝手に納得してるとかホント笑える。
お前のママじゃないんだからちゃんと説明しないと分かんないって。
>>512は真摯に答えてるじゃん
518:login:Penguin
08/05/22 01:13:47 LED49E/n
程度の低い煽りは書けば書くほど恥さらしなんだが・・・
519:login:Penguin
08/05/22 01:13:51 oyxtcAu/
>>514
さんくす
ext3の例が一番多くみつかるね。
520:login:Penguin
08/05/22 01:15:37 +J7mssJ7
ファイルシステム詳しくないけど、ext3かreiserかxfsのうちから
好みで選べば良いと思うよ。
個人的にはjfsの感想が聞いてみたいけど。
なんで誰もjfsを使わないのかが気になったり…。
521:login:Penguin
08/05/22 01:27:07 xpIrNoHG
俺はシングルコアだから使わない。ただマルチコアの人がなぜ使わないのか疑問。
522:login:Penguin
08/05/22 01:40:40 OYg2rg/p
>>519
お前、本当になにも知らない馬鹿だったんだな…
523:login:Penguin
08/05/22 01:47:23 OYg2rg/p
>>520-521
とりあえず、このスレのログを読め。
>>522
蛇足的自己レスすると、ほとんどのディストリビューションでデフォルトfsの
ext3が一番多いのは当たり前
だいたい、上に乗っかるのがsambaだろうがなんだろうが、下のfs層にとっては
あまり関係なく、ファイルサイズ等についてはなにも触れていないし。
まあ、こういう頭の悪いヤシもときどき湧いてくるスレだけどさ…
524:login:Penguin
08/05/22 02:11:20 nmRfdow3
>>523
どうせ件の悪臭公害男は>>519以降はこのスレ読みもしないでしょ。
ってことで、悪臭公害男がいかに馬鹿なのかなんて説明せんでもわかることだし、
放置しとけ。ヲレが一度煽るだけで十分だ罠。
525:login:Penguin
08/05/22 02:26:58 LED49E/n
.>523-525
あのさー、教えてもらった事について>>513はまずいレスだと思うよ。
でも君らの対応はそれを遥かに下回って恥さらしだろ。
元質問の>>505は
・(Linuxで)sambaサーバー
・2Tのストレージ
・扱うファイルサイズは50MB～2GB
って出してるのに、それを無視して話進めるのはどうかな。
>>519
見てる事を期待して。ext3使っとけ。安定してる、情報が多いという利点がある。
526:login:Penguin
08/05/22 02:45:29 nmRfdow3
>>525
でも、>>513以前に>>511のような煽りをしている時点でキチガイ確定でそ、こいつ。
いい加減放置しようよ…
527:login:Penguin
08/05/22 04:05:56 FEtNCgqq
>>505
ファイルサイズ的にH264(SD/HD)あたりの動画ライブラリとか？
基本はext3一択でいいと思うけど、余裕があれば
巨大ファイルを連続して配置しやすい(→READ時のファイル内シークに影響)のと、
オンラインデフラグ(xfs_fsr)がほぼ標準で使えるXFSを検討してみるのも乙かと。
528:login:Penguin
08/05/22 07:15:31 oyxtcAu/
>>513はいいすぎだった。悪かった。
他の皆さんもスレの雰囲気悪くして申し訳ない。
これで消える事とします。
>>520>>525>>527
レスども。参考になります。ext3、xfsを試験的に使ってみます。
529:login:Penguin
08/05/22 09:27:44 itWQcnkn
よく分からんならとりあえずext3ってのが普通の考え方では
530:login:Penguin
08/05/22 15:16:32 gmG2tmnb
大きなファイルが主体ではなくて、作成/削除が多い使い方で、2Tぐらいならreiserfsだな。
sambaの設定の方が面倒くさい。
531:login:Penguin
08/05/22 17:50:22 CrQ6/Ptu
レイザーはでかいファイル消すのがなんか遅いから/home はxfsにしてるな。
/ はレイザー。
532:login:Penguin
08/05/22 19:13:37 2reFG8Md
巨大なファイルの扱いはなんといってもxfsだよな。
ところで/でreiserするときnotailつけてっか？つけててもきちんと動くことは動いたりするんだが・・・。
533:login:Penguin
08/05/22 20:54:15 35SUYurt
>>520
俺と一緒にJFS使おうぜ。
別に問題出てないし。PowerPC Ubuntuでも問題無しだぜ。
多分世界的に運用例少ないだろうけど。
534:login:Penguin
08/05/23 18:10:09 JvrXzXX6
>>533
以前も書いたけど、漏れはクラスタの共有ディスクに使ってたよ
中身はapacheのコンテンツやCGIやログ、postgresのDBなんかだった
以前、RH+apacheでコンテンツやログをext3においてたら、不安定
になって再起動した時にジャーナルがおかしくなったらしくて
ログの一部が別のファイルのケツに追加されていて絶望した！
ので、DirtyPageが少ないと解説されてたJFSに乗り換えた
かなり古いRHの話なんで、今のext3はダイジョブかもしれない
JFSには特に問題は起こってなかったよ、オレが辞めるまでは
535:login:Penguin
08/05/25 10:22:19 I72gntmD
で，Reiser はどうなっちゃったの？
ZFSは面白そうだなぁ。
でもチキンな俺は ext3 子か使わない。
536:login:Penguin
08/05/25 10:30:38 nRuClOB5
Reiserは檻の中
537:login:Penguin
08/05/25 11:02:31 I72gntmD
ん～結局殺人を犯していたってことなの？
事実が分んないなぁ．死体もないんでしょ？
538:login:Penguin
08/05/25 11:59:37 hIhEerJj
>>508
お前試してすらいねえだろ
539:login:Penguin
08/05/25 12:10:58 aGIQLT5K
>>537
でも、車の車内を水洗いして床に何センチも
水が溜まるとか普通はやらないよな
540:login:Penguin
08/05/25 12:37:17 +SiTZLz+
>>539
個人でファイル実用的なファイルシステムを開発して何万人にも
支持されるとか普通はやらないよな
541:login:Penguin
08/05/25 12:38:56 nRuClOB5
>>538
D:\home\test>dir /b
D:\home\test>copy nul > nullpo.
D:\home\test>dir /b
nullpo
D:\home\test>del nullpo
D:\home\test>dir /b
D:\home\test>copy nul > nullpo.
D:\home\test>dir /b
nullpo
D:\home\test>del nullpo.
D:\home\test>dir /b
D:\home\test>
これはどう見たらいいんだろ？
よくわからんけど、ファイルシステムかcmd.exeのどちらかが.を完全無視しているのは間違いないけど。
ちなみにファイル名をクォートしても結果は同じ。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4653日前に更新/225 KB
担当:undef