2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :login:Penguin:2006/11/25(土) 21:24:41 ID:BgxtdIS9
過去スレ

01 http://pc.2ch.net/test/read.cgi/linux/1006743807/
02 http://pc5.2ch.net/test/read.cgi/linux/1063025258/
03 http://pc8.2ch.net/test/read.cgi/linux/1101495293/
04 http://pc8.2ch.net/test/read.cgi/linux/1136695633/
05 http://pc8.2ch.net/test/read.cgi/linux/1152348695/

2 :login:Penguin:2006/11/25(土) 21:30:24 ID:i4K5FFzZ
ext4
http://www.bullopensource.org/ext4/

reiserfs/reiser4
http://www.namesys.com/

xfs
http://oss.sgi.com/projects/xfs/

jfs
http://jfs.sourceforge.net/

nfs
http://nfs.sourceforge.net/

ntfs
http://linux-ntfs.sourceforge.net/

fuse
http://fuse.sourceforge.net/

3 :login:Penguin:2006/11/25(土) 21:34:37 ID:5Uh5FC/9
    <○√   棒人間。本スレの主役。
     ‖     格好いい事言ってみんなを逃がそうとするがすぐ死ぬ。
     くく     お調子者だが正義感溢れる熱血青年。一番数が多い。

    <●√   ブラック。棒人間の親友。
     ‖     棒人間とほぼ互角の力を持つ頼りになる男。
     くく     棒人間とともに糞スレを支えるぞ。

    <★√   スターマン。棒人間とは互いに競い合うライバル同士。
     ‖     かなりの力を持つが天井には敵わない。
     くく

    <□√   たまに出てくる四角顔。天井を支えやすいらしい。
     ‖      
     くく

4 :login:Penguin:2006/11/25(土) 21:36:48 ID:5Uh5FC/9
________________   
    <○√ <どんなに抗っても運命は変えられないかもしれない
      ‖    だが、そこに生きた証だけは違うと信じたい・・・
     くく

________________   
      <○√
    ニャー ‖  
      hoくく
    スリスリ…

  i                         
  |    i!   |    l|     i!    |     <にゃああああああああ!!
_l|i|_|_li|__l!__liil___li|__l!__    

5 :login:Penguin:2006/11/25(土) 23:48:11 ID:JuMuth85
で、全スレ最後のネタだが、rsyncが悪いのか?

6 :login:Penguin:2006/11/26(日) 00:02:55 ID:uAPikEUp
そのネタを前スレの梅ネタに汁

7 :継続中:2006/11/26(日) 16:55:21 ID:0hxeOY4W
967 :login:Penguin:2006/11/24(金) 08:20:00 ID:DPMfSxwp
誰か実験で一つのパーティションに300万ファイルぐらい置いて、
毎日別のパーティションにrsyncでバックアップするのの実験やってみない?
RHEL4のメールサーバでext3使ってると1〜3ヶ月で、
バックアップ先のファイルシステム壊れ出すよ。

ext3以外のファイルシステム使えば壊れないのか知りたい。

989 : ◆IIiDC8JS7w :2006/11/26(日) 01:40:31 ID:UfgRl6db
3年=1095回で300万以上のファイルで
さらにダミーファイルのファイルの追加と削除を繰り返し
100ユーザで本物spamも受信するようにして、より現実的に。。
一定時間でrsyncするスクリプトを11/25 19時から流してきました。

5、6分で1回rsyncするので4日ぐらい待ってください。
4ノード(Woodcrest x86_64)とディスク32玉しか確保できなかった。
kernel2.6.19-rc6-mm1
ext2、ext3、ext4dev、xfs、reiserfs、jfs
パーティションが別とは、同一ディスク?別ディスク?
聞くのが面倒だったんで両方やってるけど。。

Anode ext4dev reiser xfs 9玉
Bnode reiserfs ext3 ext2 9玉
Cnode xfs ext3 ext2 9玉
Dnode jfs ext4dev 5玉

mmkernel使ったけど、reiser4は1時間でpanicし、
vfatは遅すぎなのでやめました。。

8 :login:Penguin:2006/11/26(日) 17:27:26 ID:YzlmTHts
998 名前:967
2006/11/26(日) 15:28:59 ID:x84UIuM7
>>989
うわっ、テストが本格的。感謝感謝。

> パーティションが別とは、同一ディスク?別ディスク?
バックアップ元がハードウェアRAID1の1パーティーションで、
バックアップ先が別の単体HDD。

CPU: Athlon64
メモリ: 2GB
OS: RHEL 4 x86_64

2台運用していて、両方で発生します。
ただバックアップ先はRAID1してないので、セクタ破損の可能性高いと思います。

9 :login:Penguin:2006/11/26(日) 17:27:56 ID:YzlmTHts





>2台運用していて、両方で発生します。
>ただバックアップ先はRAID1してないので、セクタ破損の可能性高いと思います。






10 :967:2006/11/26(日) 17:46:31 ID:x84UIuM7
訂正です。
2台のウチ、1台はバックアップ先もRAID1にしてました。
そのRAID1にしてる方でmessageログをgrepしたところ、
以下のようなログが見つかったのですが、これってどこが原因なんでしょうか?

Nov 25 04:00:41 www kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Nov 25 04:00:41 www kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=103224937, high=6, low=2561641, sector=19140664
Nov 25 04:00:41 www kernel: end_request: I/O error, dev 03:08 (hda), sector 19140664
Nov 25 04:00:41 www kernel: EXT3-fs error (device ide0(3,8)): ext3_readdir: directory #1196033 contains a hole at offset 0
Nov 25 04:00:43 www kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Nov 25 04:00:43 www kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=120788585, high=7, low=3348073, sector=36704312
Nov 25 04:00:43 www kernel: end_request: I/O error, dev 03:08 (hda), sector 36704312
Nov 25 04:00:43 www kernel: EXT3-fs error (device ide0(3,8)): ext3_readdir: directory #2293762 contains a hole at offset 0

11 :login:Penguin:2006/11/26(日) 17:49:51 ID:u2118iB9
ケーブルかHDDか、いずれにしろ普通はハードウェア系と思われますね。
ドライバでバグってるときもたまにこういうエラー出ますが。

12 :login:Penguin:2006/11/26(日) 18:15:07 ID:N1CLRFC8
>>10
ぐぐってもHDがクラッシュする予兆とかしか出てこないけど...?

シーク失敗->よってリードできない->修正不能エラー->fsもエラー出力じゃないの

13 :login:Penguin:2006/11/26(日) 18:17:34 ID:N1CLRFC8
あととりあえずpioにしてみてエラーがでないようであればDMA回りかドライバで、
それでも同じようにエラーでるならhddがまずい、んじゃないでしょうか。

14 :login:Penguin:2006/11/26(日) 18:26:17 ID:sgdsyv/U
fc5かその辺でdmraidかなにかがめちゃ不安定で鳥変えたことがある。
FedoraもRHELも同じようなもんだから、多分その回りが腐ってるのかもね。

15 :login:Penguin:2006/11/26(日) 18:42:19 ID:XsQxK8M4
HDDのインターフェースがVIAだったりしないよな・・・・・
CPUがAMDだったりしないよな・・・・


16 :967:2006/11/26(日) 19:06:53 ID:x84UIuM7
>>11-15
なるほど、ハードウェアかドライバ周りでしたか・・・。
通りで似たような構成のサーバで、HDDを取り替えても起きる訳ですね。

> CPUがAMDだったりしないよな・・・・
Athlon64です・・・。

というわけで、あとはスレ違いになるので、
今度サーバ止めれる時にいろいろ実験してみたいと思います。
ありがとうございました。

17 : ◆IIiDC8JS7w :2006/11/26(日) 20:36:54 ID:UfgRl6db
Σ(゚Д゚)ガーン
昨日からのテストはいったい。。。

どうせなんで、11/30 19:00まで流してますよ。
ちなみにディスクは2年前の
ST3400832AS (400GB SATAII 7200rpm)


18 :login:Penguin:2006/11/26(日) 21:19:41 ID:3iokBptU
>15
>CPUがAMDだったりしないよな・・・・

ずいぶん旧いタイプのIntel工作員だにゃ

19 :login:Penguin:2006/11/26(日) 22:11:56 ID:x84UIuM7
>>17
そのテスト、それはそれでFSのいい比較になりそうですねー。
それぞれのパフォーマンス比較もあるとさらにいいかと。

20 :login:Penguin:2006/11/26(日) 22:18:39 ID:x84UIuM7
以下の構成でbonnie++-1.03aのベンチマーク取ってみたので、貼り。
しかしext3だとFileがCreateテストしか行われない。なぜだろう・・・。

CPU: Intel Core2 Duo E6600 2.40GHz
メモリ: nonECC DIMM 2GB
HDD: 250GB 7200rpm RAID1
OS: CentOS 4.4 i386
FS: ext3

------Sequential Output------ --Sequential Input- --Random-
Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
35061 73 37674 13 20478 6 29718 68 62840 11 186.5 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
31429 87 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

21 :login:Penguin:2006/11/27(月) 00:16:05 ID:0mSVab+o
とにかくファイルのアクセス速度を重視したFSってお薦めありますか?

22 :login:Penguin:2006/11/27(月) 00:38:45 ID:mgDpZR80
tmpfs

23 :login:Penguin:2006/11/27(月) 01:05:45 ID:cfi4pI48
reiser4

24 :login:Penguin:2006/11/27(月) 01:06:16 ID:9Y+78YyZ
やはり一理も二理もあったわけだなw


25 :login:Penguin:2006/11/27(月) 03:08:12 ID:ygih2dGe
397 :login:Penguin:2006/09/12(火) 22:57:38 ID:nKd1xEVn
>>367
先月に各ファイルシステムの状況知識のリフレッシュを兼ねて
jfs/xfs/ext3/reiserfs/reiser4で各状況をpostmarkで試験してみたよ。
バッチで回してまる4日かかった。

そしたら、スモールファイル・フォルダ内大量ファイル、の条件では

 reiserfs>xfs>>jfs>reiser4>>>>ext3

となった。ただし、reiserfs...jfsまでで速度が一割も
変わらないので、たしかに差はあるが、reiserfs/xfsはほぼ同格。
ちょっと離れてjfs/reiser4が団子。大差でext3。なお、writeに
重点を置くとxfs>reiserfsとひっくり返る。また、ext3はbtreeで
mkfsしてないことに注意。

ちなみに、フォルダ内大量ファイルの条件を外すと、ext3がrd/wr/wrの
どの条件でも大差でトップになった。

まだ処理速度しか集計してないので、処理中のプロセッサ使用率とかに
差があったか(負荷高くて速くても意味なし)はまだ不明。他にも
スペース利用効率も比較の予定だけど、まだしてない。

398 :login:Penguin:2006/09/12(火) 22:58:24 ID:nKd1xEVn
誤:ただし、reiserfs...jfsまでで速度が一割も変わらない
正:ただし、reiserfs...reiser4までで速度が一割も変わらない

26 :login:Penguin:2006/11/27(月) 03:09:16 ID:ygih2dGe
413 :login:Penguin:2006/09/13(水) 23:33:58 ID:Mu/xe+3x
>>410
えっと、データ的には

set size 500 15000
set number 10000
set subdirectories 1
set transactions 100000
set bias read 5
set bias create 5
run
quit

を postmark に食わせてる。なので10000ファイルが単一フォルダ内に
ある形。結果自体はまだ集計中なので一部だけ出すと

=== s-rw-single ===
ext3 121.1 120.0 120.0 120.0 121.0 122.0 122.0 122.0 122.0
jfs 94.2 92.0 93.0 93.0 94.0 94.0 95.0 96.0 97.0
reiser4 98.4 97.0 98.0 98.0 98.0 99.0 99.0 99.0 99.0
reiserfs 85.1 84.0 84.0 85.0 85.0 85.0 86.0 86.0 86.0
xfs 88.4 87.0 88.0 88.0 88.0 89.0 89.0 89.0 89.0

となっている(単位は秒)。最初のデータ列は平均値で、残り8つが
実測値。(続く)

27 :login:Penguin:2006/11/27(月) 03:10:01 ID:ygih2dGe
で、集計終わる前でなんだけど、性能とリソース消費のところまでを
見た感じではxfsの評価が高い。ただし、クラッシュ時の挙動は
これから確認(というかXFSはちょっとクセがあるんだけど)なので、
これだけで選定するのはさっき書いたように早計だけど。

まず速度はsmall/medium/largeのどの領域でもトップクラスにおり、
その一方で、いずれのケースでもプロセッサを他より消費しない。
つまり、他の処理と並行処理する余裕がある。small領域では
jfsもまあまあだけど、medium-largeとなるにつれ、jfsはext3/reiser*
同様に使い切るようになるのに、xfsは常時処理に余裕がある。
遅くて余裕があるなら当然だが、速くて余裕があるのは正直驚いた。

あと、small領域でwait状態の発生量が少ない。つまり、プロセッサは
空いているか、それとも本当に使っているかで、I/O waitが発生しにくい
何らかの設計・実装になっているのだと思う。medium-large-fileに
なるとさすがにI/Oだらけなのでwaitが同程度になってしまうけどね。

28 :login:Penguin:2006/11/27(月) 03:11:43 ID:ygih2dGe
あと気づいたのが、fsによって処理中のコンテキストスイッチの
入り方が違う。これはxfs/jfsとext3/reiser*グループに分けられて、
前者は後者の10-20倍スイッチングする。

カーネルハッカーな人に教えて欲しいんだけど、これはxfs/jfsでは
処理が細粒度に分割されていて、プリエンプトしやすい、つまり
マルチプロセッサ時のスケーラビリティやリアルタイム処理向きに
なっているという理解で正しい?XFSは元々その領域を得意として
いたので、I/O waitの少なさも生まれが影響しているのかも。

29 :login:Penguin:2006/11/27(月) 03:13:23 ID:ygih2dGe
421 :login:Penguin:2006/09/14(木) 10:16:36 ID:E8DSb0pK
reiser4については、s-rw-small試験の性能だけでは劣っているように
見えるけど、たしかに改良されてるよ。性能差以上にプロセッサ利用率が
確実に低減してるし、性能自体もmedium-large領域ではきっちり逆転してる。

並行処理時の性能変動については、ext3などは自分がCPUを掴んで
しまうので、それ自体の性能は落としにくいけど、占有状態に
なるので他が結局走れない状態、でもってxfsとかは小まめにCPUを
離すので、スケジューラがより優先度の高い実処理の方に廻してると
理解してる。つまり、スケジューラの性能次第だけど、よりスループットが
高くなるのはxfs/jfsだと思う。

30 :login:Penguin:2006/11/27(月) 03:43:21 ID:gqe6EGX+
>>24
日本語がおかしい

31 :login:Penguin:2006/11/27(月) 05:10:04 ID:Hueq7Ycv
Mac OS X の HFS+ で postmark 実行してみた。

CPU: Intel Core 2 Duo T7400 2.16GHz
Memory: 2GB
HDD: WD3200JS (320G SATA300 7200)

Time:
910 seconds total
840 seconds of transactions (119 per second)
Files:
60152 created (66 per second)
Creation alone: 10000 files (3333 per second)
Mixed with transactions: 50152 files (59 per second)
50120 read (59 per second)
49666 appended (59 per second)
60152 deleted (66 per second)
Deletion alone: 10304 files (153 per second)
Mixed with transactions: 49848 files (59 per second)
Data:
469.56 megabytes read (528.38 kilobytes per second)
566.22 megabytes written (637.15 kilobytes per second)

この場合、総合タイムは119秒ってことかな。
前スレ397の人のCPU、HDDの情報欲しいねー。

32 :login:Penguin:2006/11/27(月) 05:46:42 ID:Hueq7Ycv
さらに Mac OS X の UFS で postmark 実行してみた。
総合タイムは最初の秒みたいね。
なので、HFS+が910秒でUFSが321秒ってことかな?
あとCPU使用率がHFS+は3〜5%だったのに、UFSは25〜30%ぐらいだった。

Time:
321 seconds total
311 seconds of transactions (321 per second)
Files:
60152 created (187 per second)
Creation alone: 10000 files (1666 per second)
Mixed with transactions: 50152 files (161 per second)
50120 read (161 per second)
49666 appended (159 per second)
60152 deleted (187 per second)
Deletion alone: 10304 files (2576 per second)
Mixed with transactions: 49848 files (160 per second)
Data:
469.56 megabytes read (1.46 megabytes per second)
566.22 megabytes written (1.76 megabytes per second)

33 :login:Penguin:2006/11/27(月) 06:26:35 ID:Hueq7Ycv
Linuxサーバでも試してみた。
早朝とはいえ低負荷で稼働中のサーバだから、少しだけ遅くなってるかも。

CPU: Pentium 4 2.80GHz
Memory: 2GB
HDD: 160GB ハードウェアRAID1
OS: RHEL 3
FS: ext3

Time:
 324 seconds total
 311 seconds of transactions (321 per second)
Files:
 60152 created (185 per second)
  Creation alone: 10000 files (1428 per second)
  Mixed with transactions: 50152 files (161 per second)
 50120 read (161 per second)
 49666 appended (159 per second)
 60152 deleted (185 per second)
  Deletion alone: 10304 files (1717 per second)
  Mixed with transactions: 49848 files (160 per second)
Data:
 469.56 megabytes read (1.45 megabytes per second)
 566.22 megabytes written (1.75 megabytes per second)

前スレ397の人、一部のデータ出したって書いてあるけど、どのデータ出したんだろう。
最初の行のタイムにしては3倍近く差が付くのは変なような・・・。

34 :login:Penguin:2006/11/27(月) 11:39:35 ID:zIhTBo3A
俺も似たような状況
Athlon64x2、CentOS4 x86_64、VIA
でmdまわしてたけど
数日後には同じようなエラーが出てどうしても止まる。
HDDもケーブルも変えまくったけど駄目ぽなので
ドライバがくさってるなと結論づけ諦めた。
しばらく32ビットOSでやってたら普通に動いてたけど、
64でやる必要あったので、mdはずしますた。

というわけで32ビットOSでまわすのはどうでしょうか。

35 :login:Penguin:2006/11/27(月) 12:15:13 ID:V5iOSjFK
前すれ397はext3をdir_indexなしでフォーマット
しているので参考にならない。

36 :login:Penguin:2006/11/27(月) 14:13:05 ID:NL+5TZr7
(´,_ゝ`)プッ

37 :login:Penguin:2006/11/27(月) 14:23:46 ID:Gl6W36sR
(´゚c_,゚` )プッ

38 :login:Penguin:2006/11/27(月) 15:06:39 ID:mo7iZrU6
思考実験、ドイツ語ではゲダンケンエクスペリメントはもう終わりましたか?


39 :login:Penguin:2006/11/27(月) 23:11:33 ID:1WMqFMtM
ext3は高負荷のときに壊れる
xfsにも微妙なところがある
jfsは論外


40 :login:Penguin:2006/11/28(火) 02:08:45 ID:dIATTNIe
チラシの裏にどうぞ

41 :login:Penguin:2006/11/28(火) 07:13:42 ID:J+dhV7qO
だからXFSでいいんでしょってのに。

42 :login:Penguin:2006/11/28(火) 08:15:30 ID:cRzA/Bi/
Linuxのカーネル自体が、高負荷に弱いからなw


43 :login:Penguin:2006/11/28(火) 08:36:33 ID:mWLPxpmO


   ま  た  抽  象  論  厨  か



いい加減にしろよハゲ

44 :login:Penguin:2006/11/28(火) 22:57:31 ID:5TqPHx8Y
ファイルの読み出しを大量に行ったら、全プロセスが 1 分以上動かなくなったことがある。(+д+)

45 :login:Penguin:2006/11/28(火) 23:03:16 ID:ZKWZRDmg
>>44
おらくSCSI bus reset

46 :login:Penguin:2006/11/28(火) 23:06:41 ID:+IZBoTgF
いやNFSというオチ

47 :login:Penguin:2006/11/28(火) 23:07:50 ID:12X1ZwKm
ぬ。
おそらく、ね。

48 :login:Penguin:2006/11/29(水) 11:46:21 ID:4v2KUCQc
macのドライブにアクセスする方法ありませんか?

49 :login:Penguin:2006/11/29(水) 12:09:14 ID:IMfnsoFA
samba

50 :login:Penguin:2006/11/29(水) 20:53:33 ID:lIbQSUXt
>45
そんなことで 1分も時間がかかるのか?

51 :login:Penguin:2006/11/29(水) 23:42:54 ID:a8L0fs7M
2.6.19-rc6 とかで generic file writeとか
削除されてるだんけど何で?

52 :login:Penguin:2006/11/30(木) 06:52:55 ID:174bag3/
ttp://sfgate.com/cgi-bin/article.cgi?f=/c/a/2006/11/28/BAGERMLCGJ38.DTL

> Today, attorney Daniel Horowitz withdrew from the case, saying Reiser
> couldn't afford his services.
>
> "This is an incredibly complex case," Horowitz said in an
> interview. "It requires hundreds of hours of intense work and a major
> amount of staff involvement. He actually can't afford me. There's no
> money."

Hansたんはお金がなくっていい弁護士を雇えなかったみたいだぞ。
弁護費用の募金活動やらね?

53 :login:Penguin:2006/11/30(木) 07:06:37 ID:rKSOEWU+
>>52
なんだ、まだ死体も見つかってないどころか、死んだかどうかの
確認すらできてないんじゃん。

なんか証拠が見つからなくなって面倒くさくなった警察側が
寝技使って落しどころ探してるって感じなんじゃないのか。ひどい。

54 :login:Penguin:2006/11/30(木) 07:42:45 ID:wl2BA0uA
Andrewの陰謀だ

55 :login:Penguin:2006/11/30(木) 07:47:16 ID:xHQdO+fK
どの国も警察っていいかげんだなあ。


56 :login:Penguin:2006/11/30(木) 15:17:18 ID:xxzhfaCv
>>55
何人もが行方不明になっても、何年も放置しておく警察もあります。

57 :login:Penguin:2006/11/30(木) 15:18:33 ID:8qpZwMYe
>>56
だっている場所分かってるニダ

58 :login:Penguin:2006/11/30(木) 18:30:13 ID:xxzhfaCv
へぇ、JFSって意外にまともに属性管理できるんだ。


EXT3
# lsattr
suS-iadAcj--T ./test_file
suSDiadAcj--T ./test_dir

ReiserFS
# lsattr
lsattr: Inappropriate ioctl for device While reading flags on ./test_file
lsattr: Inappropriate ioctl for device While reading flags on ./test_dir

XFS
# lsattr
--S-iadA----- ./test_file
--S-iadA----- ./test_dir

JFS
# lsattr
suS-ia-A----- ./test_file
suSDia-A----- ./test_dir



59 :login:Penguin:2006/11/30(木) 19:36:11 ID:MWVY75+p
aclは全部完全に管理できなきゃ意味ないw
不完全ならない方がいい。


60 :login:Penguin:2006/11/30(木) 20:21:32 ID:mmMkv7Ur
aclとattributeはちがうだろ

61 :login:Penguin:2006/11/30(木) 21:26:40 ID:3HsodbO8
しーっ

62 : ◆IIiDC8JS7w :2006/11/30(木) 23:44:34 ID:3D2vx2Hv
1095回(3年分)のrsyncの結果。11/30 21:00完了
ext4dev ext3 ext2 reiser xfs jfs
に異常は見られませんでした。。
普通に稼動してました。

各FSは最初300万ファイルでしたが、
(100users, 1userあたり30000通のメールと仮定)
たった4日間で900万ファイルになってしまいました。
つまり差分の1userあたりの60000通は全部spam。。。
ディスク使用量は130Gぐらい増えてた。。

メールファイルのため、ファイルの更新は無く、
ファイルの追加のみの差分rsyncだったので、負荷が
少なめだったのかもしれません。

今回使用した評価環境は、メールサーバ用として
贅沢すぎたかな。。

63 :login:Penguin:2006/11/30(木) 23:56:49 ID:aEiu/0E7
>>62
お疲れさまー。
やはりFSとrsyncだけでは問題は出ないようですね。
カーネルやドライバのバグ、ハードの問題などが原因でしょうか。

64 :login:Penguin:2006/12/01(金) 02:21:18 ID:hovM2rQ4
OSCON2006でFS比較話があって、内容自体はほとんどこのスレと
同じなんだけど、1つだけ「JFSはIBMに捨てられたのが欠点」という
話があったらしい。これ何のこと?


65 :login:Penguin:2006/12/01(金) 03:08:08 ID:XMuKng2p
>>31

ZFSスレに宣伝が来たので、ZFSでやってみた。
マシンは、ThinkpadX30(10thAniversaryModel)

Creating files...Done
Performing transactions..........Done
Deleting files...Done
Time:
59 seconds total
55 seconds of transactions (1818 per second)

Files:
60152 created (1019 per second)
Creation alone: 10000 files (3333 per second)
Mixed with transactions: 50152 files (911 per second)
50120 read (911 per second)
49666 appended (903 per second)
60152 deleted (1019 per second)
Deletion alone: 10304 files (10304 per second)
Mixed with transactions: 49848 files (906 per second)

Data:
469.56 megabytes read (7.96 megabytes per second)
566.22 megabytes written (9.60 megabytes per second)

こんな感じです。ZFS上に構築したSolarisZoneで実行した。

66 :login:Penguin:2006/12/01(金) 03:22:36 ID:XMuKng2p
結果見直してみるとちょっと速すぎるな・・・
何かベンチのパラメータ落としたかな??UFSとZFSでもう一度取り直してみる。

67 :login:Penguin:2006/12/01(金) 03:42:44 ID:XMuKng2p
同じマシンのUFS上でやってみた。
なんじゃこりゃー!

Creating files...Done
Performing transactions..........Done
Deleting files...Done
Time:
1253 seconds total
1211 seconds of transactions (82 per second)

Files:
60152 created (48 per second)
Creation alone: 10000 files (1250 per second)
Mixed with transactions: 50152 files (41 per second)
50120 read (41 per second)
49666 appended (41 per second)
60152 deleted (48 per second)
Deletion alone: 10304 files (303 per second)
Mixed with transactions: 49848 files (41 per second)

Data:
469.56 megabytes read (383.74 kilobytes per second)
566.22 megabytes written (462.74 kilobytes per second)

68 :login:Penguin:2006/12/01(金) 03:43:15 ID:XMuKng2p
そしてもう一度ZFS。・・・・
誰か解説してくれー

Creating files...Done
Performing transactions..........Done
Deleting files...Done
Time:
61 seconds total
58 seconds of transactions (1724 per second)

Files:
60152 created (986 per second)
Creation alone: 10000 files (5000 per second)
Mixed with transactions: 50152 files (864 per second)
50120 read (864 per second)
49666 appended (856 per second)
60152 deleted (986 per second)
Deletion alone: 10304 files (10304 per second)
Mixed with transactions: 49848 files (859 per second)

Data:
469.56 megabytes read (7.70 megabytes per second)
566.22 megabytes written (9.28 megabytes per second)

69 :login:Penguin:2006/12/01(金) 04:13:20 ID:HVWtIxPt
異常な速度だなぁ。ZFSは実際にディスクには書いていないんじゃないの?

70 :login:Penguin:2006/12/01(金) 10:35:57 ID:mEhJq9GL
>>65-68
なんじゃこりゃー。
化け物だ・・・。

乙です。

71 :login:Penguin:2006/12/01(金) 11:34:02 ID:y8bRU7K1
>>69
それは某FSに対する
なにかだな

72 :login:Penguin:2006/12/01(金) 11:45:31 ID:mq6YGmUl
ここはもう奥村(だっけ?)の出番だな

73 :login:Penguin:2006/12/01(金) 23:09:35 ID:B+5xJghb
project DOUBT!

74 :login:Penguin:2006/12/01(金) 23:54:36 ID:SU1ozKXb
>>72
俺?それともTexの?

75 :login:Penguin:2006/12/02(土) 00:08:01 ID:8gMXyV52
fjの教祖様だろ


76 :netadesu:2006/12/02(土) 00:20:56 ID:h0fdrb+a
>>71
UFSは磁石が弱くてもしっかり記録されるように10回上書きしてる。
昔のHDDに対応するための仕様。このため最近のHDDだと5回位間違って
削除してもundeleteできる。


77 :login:Penguin:2006/12/02(土) 00:58:04 ID:t53s4AAE
>>68
参考になるかも。
http://spam.workaround.ch/dull/postmark.txt


78 :login:Penguin:2006/12/02(土) 02:38:56 ID:lPnc7z93
>>77
逆っすよ逆。
リンク先だとZFS激遅で、UFSの方が速いじゃない。
Reiser4はもっとバカっぱやだが。

79 :login:Penguin:2006/12/02(土) 06:20:06 ID:hUvReIbv
> UFSは磁石が弱くてもしっかり記録されるように10回上書きしてる。
> 昔のHDDに対応するための仕様。このため最近のHDDだと5回位間違って
> 削除してもundeleteできる。

[これはひどい]

80 :login:Penguin:2006/12/02(土) 08:06:41 ID:XkytH5qu
UFSが異常に遅いだけなんだよな

81 :login:Penguin:2006/12/02(土) 08:35:44 ID:JnqgzHJZ
ext4関連
ttp://www.atmarkit.co.jp/flinux/rensai/watch2006/watch11b.html

82 :login:Penguin:2006/12/02(土) 09:45:37 ID:sH3vo8pi
postmarkの設定を比較。

このスレ
set size 500 15000
set number 10000
set subdirectories 1
set transactions 100000
set bias read 5
set bias create 5

>>77 の Test #1
set size 300 800
set number 50000
set transactions 500000

>>77 の Test #2
set size 800 8000
set number 12000
set transactions 80500

大きな違いはなさそう。
あとはZFSのバージョンが違うとか?

83 :login:Penguin:2006/12/02(土) 11:04:37 ID:eQc2JRBC
以前2chに流れた情報とメーカから得た情報から推測すると、
・ZFSはファイルのcread/deleteは異常に速い
・ZFS RAID-ZはソフトウェアRAID5なのにシーケンシャルread/writeがすごく速い
・ZFS RAID-Zはディスク本数を増やしていくとどんどん速くなる
・ZFS RAID-Zのランダムread/writeは今ひとつ(SATAの時)
だれかSCSIかFCを10-20本使って試験してみて欲しい。

84 :login:Penguin:2006/12/02(土) 20:36:07 ID:bhOq8sLd
dump/restore によるバックアップって、
激しく稼働しているシステムに関しては
整合性が失われるためによくないのでしょうか?

一度システムを停止して、Knoppix のようなもので
CDブートしてバックアップを取るのが理想なのでしょうが、
システムが稼働中にスナップショット的にバックアップを
取るというのは dump では難しいですか?

LVM を使うべきなのでしょうか?

85 :login:Penguin:2006/12/02(土) 20:55:18 ID:ABKO4Jin
LVM2は稼働中のシステムのスナップショットを取れない。固まる。

86 :login:Penguin:2006/12/02(土) 22:07:53 ID:eQc2JRBC
>>84 スナップショットをしたところで、タイミングによってはデータ不整合に
陥る。要するに確率の問題。
確実にバックアップ取りたければ、writeが発生しない状況で取るしかない。
マルチユーザならばtelnetやssh、ftp、NFS、Samba、メールサーバ等の
サービスを停止。シングルに落とせば完璧だが、自動スケジューリングが
難しくなる。
もしかすると、copy on writeで64bitのchecksumを持つZFSならば、
write処理中にスナップショット取って不整合になる事は無いのかもしれ
ないけどね。

87 :login:Penguin:2006/12/02(土) 22:11:39 ID:+5VOoV6t
>>86
CoWとsnapshotのどこに関係が?

88 :login:Penguin:2006/12/02(土) 22:22:58 ID:eQc2JRBC
ZFSはファイルが確実に書かれた事を保証できるファイルシステム。
書き込み途中にシステムが落ちた場合、そのデータは捨てられる。
copy on writeなので、生きているファイルのデータブロックを壊す心配も無い。
強力なchecksumにより、ファイルの完全性が保証される。
なので、静止点を作らずとも、オンラインでバックアップできるのではない
だろうか?

89 :えぬてーてー社員:2006/12/02(土) 22:36:15 ID:gCRA9JZT
そこでnilfsですよ

90 :login:Penguin:2006/12/02(土) 22:38:23 ID:kzjFlxSY
通常の三倍の容量のディスクをお使いください。

91 :login:Penguin:2006/12/02(土) 22:41:09 ID:bhOq8sLd
>>88 それって、SoftUpdate とは別モノ?

92 :login:Penguin:2006/12/02(土) 23:15:34 ID:eQc2JRBC
>>91 実現している事はほぼ同じではないでしょうか。ZFSはcopy on writeを
利用して2^64までのスナップショットを実現しているそうです。
checksum 64bitが自分としてはすごく期待しています。ファイルシステムの
不整合問題についてはジャーナリングファイルシステムでもOKですが、ファ
イルが壊れたまんまになっているのではないかと言う不安がついてまわり
ます。

93 :login:Penguin:2006/12/02(土) 23:18:29 ID:ABKO4Jin
バックアップについては
金はけちるくせに無理難題ばかり言ってくる奴ばかりでうんざりだ。
だから最近はバックアップの事は口にしない事にしてる。
勝手にデータ失って死ねよって感じ。

94 :login:Penguin:2006/12/02(土) 23:26:50 ID:eQc2JRBC
>>93 俺もそう思う。最近は1TBを超えるシステムも少なくないんで、フルバック
アップをバックアップウィンドウ内で取る事が困難になってきた。
TapeじゃなくてDiskに取れば速いと勘違いしている人も多いし。困ったもんだ。
送り出しの方の性能(read)が問題になっているのに。

95 :login:Penguin:2006/12/02(土) 23:57:54 ID:eQc2JRBC
SolarisのUFSがext3よりも速いと言っているが本当かな?
http://www.sun.com/software/whitepapers/solaris10/fs_performance.pdf

96 :login:Penguin:2006/12/03(日) 00:12:21 ID:Dnl0qBMZ
USFloggingはpostmark専用ということでしょう。

97 :login:Penguin:2006/12/03(日) 00:18:11 ID:yq6uElX+
>>95
portmarkの結果を見るとなくはないと


98 :login:Penguin:2006/12/03(日) 00:25:11 ID:EZVqzNiE
portmarkで比較なんかされてたっけ
他所のスレ?

99 :login:Penguin:2006/12/03(日) 00:26:11 ID:18r037ES
>>96 つーか、Solarisでは標準がUFS Logging。

100 :login:Penguin:2006/12/03(日) 00:29:21 ID:18r037ES
>>98 95のファイルに

101 :login:Penguin:2006/12/03(日) 00:35:57 ID:7MHSLQFC
vine linuxをインストールした後に、windows上でrawriteを使ってgrubの起動フロッピー作った。
そして、biosでフロッピーディスクドライブを起動順位の1番上にして、再起動したら…windowsが立ち上がってしまう…汗
原因が分かる人いますか?いたら、教えていただきたいのですが…ちなみに、フロッピーディスクドライブはUSB接続なんですが、関係あるのでしょうか??

102 :login:Penguin:2006/12/03(日) 02:22:38 ID:8l+uEP+9
スレ違い
つーか機器構成ぐらい書けよヴォケ

103 :login:Penguin:2006/12/03(日) 02:26:51 ID:Hcdjmvk5
>>101
フロッピー読みに行ってるのか?
ダメならBIOSでUSBを一番優先させてみろ。


104 :login:Penguin:2006/12/03(日) 16:59:34 ID:rNEial6W
xfs_repairって、1TBのボリュームにつき1GBのメモリが必要ってどっかで見たんですが、
メモリが足りない時はどうなりますか?メモリが足りないといわれるのですか?
今やってる環境では、unable to verify superblockと途中で出てるだけで、
処理が終了しないのですが?

105 :104 :2006/12/03(日) 21:25:04 ID:rNEial6W
すいません、過去スレに必要メモリ量は、ファイル数によるとありましたので
自分の環境では、関係ありませんでした・・・

xfs_repairの問題って、2.6.19では解決済み?

106 :login:Penguin:2006/12/04(月) 10:42:22 ID:xZfcs1Y7
changelog嫁

107 :login:Penguin:2006/12/04(月) 10:54:48 ID:dSD3cIjI
>>106
低脳でもできる回答乙

108 :login:Penguin:2006/12/04(月) 23:49:18 ID:M3KqaF+X
>>99
ウソんw
/etc/vfstabのオプションでlogging指定してたらでしょ。

109 :login:Penguin:2006/12/05(火) 08:10:07 ID:X6W7O/3k
>>108 Solaris 9 9/04以降はデフォルトがUFSロギング。
http://docs.sun.com/app/docs/doc/817-7233/6mmilkdib?a=view#epfnn
この事実は意外と知られていないのな。最近も客にloggingオプション書き忘れて
いるぞとクレームつけられた。mountコマンド実行して見てよと。客苦笑い。

110 :login:Penguin:2006/12/05(火) 09:58:58 ID:iJO6AsHS
postmark以外のベンチでも同様に速ければ、ね。
デフォルトがどうのではないよ。専用というのは。

111 :login:Penguin:2006/12/05(火) 10:42:06 ID:3m+29pb2
>>109
それ以前のはSolarisと呼ぶ価値もないと?

112 :login:Penguin:2006/12/05(火) 11:55:33 ID:ZAhaU2Uy
そんないじわる言うなよ。

113 :login:Penguin:2006/12/05(火) 13:04:58 ID:58SJGa53
すみません、質問させて下さい。

mkreiserfs における -s <journal_size> オプションを
デフォルト値より増加させることにより、ファイルシステムの
初期使用容量が増加しますが、それと引き換えに
ジャーナルシステムの堅牢化やパフォーマンスの
向上等が見込めるのでしょうか。


114 :login:Penguin:2006/12/05(火) 22:23:41 ID:Uo1+tsKM
ReiserFS って作者どうなったの?

115 :login:Penguin:2006/12/05(火) 22:50:02 ID:MfwPTzkp
妻殺しの容疑で逮捕され起訴。
しかし死体も殺人の証拠も見つかっていない。
初公判でHansは無罪を主張。
いい弁護士がつけば某OJシンプソンみたいに無罪になるだろうが……
有名弁護士は「金ない奴の弁護はヤラネ」と辞任してしまう。

漏れの予想: 有罪。懲役20年。

116 :login:Penguin:2006/12/05(火) 23:04:59 ID:1ryvR00Z
>115
陰謀説もありうる


117 :login:Penguin:2006/12/05(火) 23:10:04 ID:Uo1+tsKM
死体も見つかっていないってどういうこと?
なんで逮捕されたんだろう。

118 :login:Penguin:2006/12/05(火) 23:17:39 ID:rXB4Zs2I
Hans Reiser基金があれば寄付したいなぁ。
裁判費用に宛ててもらって、無罪なら余りは全部あげる。
有罪なら余りは恵まれない北朝鮮の子供達へ。

119 :login:Penguin:2006/12/05(火) 23:21:15 ID:Hfdv8p8G
>>118
> 余りは恵まれない北朝鮮の子供達へ。
それは間違いなく子供たちに届かず核開発に流用されるだろう。

120 :login:Penguin:2006/12/05(火) 23:31:29 ID:rXB4Zs2I
じゃあ、直接将軍様にでいいや。

121 :名無しさん@お腹いっぱい。:2006/12/06(水) 00:08:21 ID:yI66B+zP
>>92
>不整合問題についてはジャーナリングファイルシステムでもOKですが、ファ
>イルが壊れたまんまになっているのではないかと言う不安がついてまわり
>ます。
つーか、ファイルシステムレベルのジャーナリングではデータ部分の整合性は
保証できないだろ。アプリが自分でやらないと。

122 :login:Penguin:2006/12/06(水) 01:06:36 ID:BnlsXkP+
>>120
氏ね

123 :login:Penguin:2006/12/06(水) 01:42:02 ID:DBbsU8xP
>>122
<#`Д´> 癇癪起こる!

124 :login:Penguin:2006/12/06(水) 08:30:11 ID:6a3HiqpI
>>121 そこでZFSですよ。256ビットのハッシュデータ。

125 :login:Penguin:2006/12/06(水) 10:12:00 ID:tCUoJ222
>>124 それはちゃんとファイルが書き込めた後での
長期的な同一性保証のためのものじゃないかな。

126 :login:Penguin:2006/12/06(水) 14:00:30 ID:ifaylv2S
HDDにデーター領域を作ったので興味本意でxfsにしてみました。ネットで結構優秀とか大きなサイズの
ファイルには良いって書いてあったのですが。。。書き込みがやたら遅いんです、1Gのファイルのコピー
をしてみたのですがext3からext3で28秒、ext3からxfsだと2分近い。読み込みは計ってませんが体感
的にはext3より早そうです。。。しかし大きなファイルの書き込みが特に遅いです('ヘ`;
これって何かの数値をチューニングしなければいけないのでしょうか?それとも自分のOSかハードがおかしい
のかな。。。ubuntu6.10-i386なんですが。

127 :login:Penguin:2006/12/06(水) 14:08:11 ID:VuLfvWGj
>>126
ハードウェア情報書いて無いから、
エスパーでもないと回答不可能。

128 :login:Penguin:2006/12/06(水) 14:57:47 ID:ifaylv2S
>>127  すみません、確かにそうですね^^;
ハード構成はAthlon4200×2、メモリ2G、チップセットGeforce4、グラボ6600GT、HDDは3台でSATA2台(
マックストアとシーゲート)、PATA1台(シーゲート)でディスクの使い方はsdaにWINXP、sdbにLinux、
hdaはデーター用です。Linuxはext3で動かしています。WINXPのntfsに書き込みが出来るntfs-3gと
いうのをインストールしてLinuxからntfsへ書き込みしてました。今回データーディスクのhdaを丸々
xfsにしてみました。
今もバックではのんびりとxfsへデーターをコピーしてますが何気にCPUパワー食ってますね。デュアルコア
が両方共10%くらいシステムモニターでふれています。

129 :login:Penguin:2006/12/06(水) 15:03:30 ID:pwSD0KnX
PIOモードになってたというオチ

130 :login:Penguin:2006/12/06(水) 15:28:52 ID:pSdv9N8K
write back cacheまわりとか?

131 :login:Penguin:2006/12/06(水) 15:37:04 ID:ifaylv2S
>>129
一瞬もしやと思ったのですがhdparmで調べるとDMAはオンです。 -t オプションで速度も計ってみました。
hdaが 45.35 MB/secでsdbは 53.92 MB/secでした。
やはり書き込みが遅いですね。読み込みの倍なんてもんではなく3倍から4倍くらいの時間がかかってます(TT)

132 :login:Penguin:2006/12/06(水) 15:44:48 ID:ifaylv2S
>>129-130 いろいろな御意見ありがとうございます^^
write back cache? ちょっとググってみます^^;

後気になった点は先程書き込みをしている状態でhdaからsdcへファイルをコピーしてみました。
これで読み書きフル稼働状態なのですがCPU稼働率が70から80へとポンポン跳ね上がります。
ファイルの読み書きだけでこれはあがり過ぎですよね?

133 :login:Penguin:2006/12/06(水) 16:03:54 ID:ifaylv2S
うわああああああ(><)
今起動しているのが2chブラウザーのv2cとシステムモニターだけ。。。
実メモリー使用が378Mって。。。なんかディスクの読み書きで使用したメモリの開放がされてない
っぽい。しかもシステムモニタで目に見えるメモリーの合計はそんないってないです。
仮想メモリーも表示にしたらjava 692M(おいおい、これ勘違いではw)それとnautilus 362M
くさい。。javaはv2cなので一度v2cをとじます。案の定メモリーは減りません。
ファイルの読み書き時もCPUパワー食っていたのがnautilusでした。これってwindosでいう
exdplorer、ようはファイルマネージャーですよね?

134 :login:Penguin:2006/12/06(水) 16:20:57 ID:ifaylv2S
ext3へ変更します。今実験したらnautilusのメモリとも違いますね。システムモニターに写らない何かが
メモリーを開放してくれません(一度でもxfsへ書き込んでしまうと)

135 :login:Penguin:2006/12/06(水) 16:26:44 ID:q9ltKIye
それDelayed Allocation

136 :login:Penguin:2006/12/06(水) 17:14:30 ID:TcRO1p0L
これは本家と無関係なんでつか?
http://www.xfs.org/
こんなドメインよくとれたな

137 :login:Penguin:2006/12/06(水) 17:15:59 ID:wIp7BUbr
>>133
ファイルシステムやVMの基本、Linuxにおける実装の特性
について勉強し直したほうが良いのでは?

http://www.atmarkit.co.jp/flinux/rensai/fs01/fs01b.html



138 :login:Penguin:2006/12/06(水) 20:13:24 ID:6a3HiqpI
ZFSのsnapshotって一瞬で終わりますね。rollebackも10秒とかからない。
2000個近いファイル、計1GB位を書き込んでrollebackしてみたのですがすぐでした
使ってみるとNetAppのDataONTAPと本当に機能が似ています。
snapshotから過去のファイルを読み出すときも、
# cp /pool/home/user/.zfs/snapshot/snap1/file . みたいな感じですから。

139 :login:Penguin:2006/12/07(木) 02:36:17 ID:TfaVgQxt
raid-z x2で片方をSVN+WevDavサーバにしたい。
そんな権力俺には無いけどね

140 :login:Penguin:2006/12/07(木) 07:40:01 ID:AQ8VWnTG
WebDAVで各ユーザのhome directoryを見せたいんだけど、認証とACLが今ひとつ
分からない。Sambaみたいに自分のhome以外はアクセスさせない設定をしたいの
ですが。

141 :login:Penguin:2006/12/07(木) 10:04:48 ID:KfNP6Zhh
WebDAV使うからわからなくなるんだ

142 :134:2006/12/07(木) 20:03:50 ID:T+r6TgE/
>>137
ファイルシステムも奥が深そうですね。当り前ですがかなり中で働いているのですね^^;
記事は参考として読んでみました。

ググってみたら私と同じような症状の方がいました。ubuntu+GONOMEのnautilusにて発生するようですが
あまり騒いでいる様子が無いところをみると出る人とそうでない人がいるのかな。もしくはxfsを使用して
サーバーとか建てる方はubuntu+GNOMEって人が少ないのかな。
データーディスクをReiserFSにしてみたらなんと調子がいいのです。ext3からext3へコピーをしたりする
よりも早い上何故かCPUパワーとメモリーを食いません^^;
>>133とまったく同じ処理をさせてメモリ使用170Mで書き込み時間は1/7ほどになりました。当分これで
いってみます。

143 :login:Penguin:2006/12/08(金) 10:31:53 ID:ta6ZGDEB
>>142
おまえは何にもわかってない。
そのページのコラムをよく読め。

ディスクキャッシュでメモリが使われる分には無害。
「メモリを余らせるのはもったいないからディスクキャッシュとしてどんどん使え」
というのがLinuxの基本的な実装方針。


144 :login:Penguin:2006/12/08(金) 15:58:51 ID:JLsqtU7n
でもCPUが全然違うみたいじゃん

145 :login:Penguin:2006/12/09(土) 03:28:56 ID:EBN5bRDP
ZFSみたいなファイルシステムが普通になってくれば、LVMなんていらなくね?

146 :login:Penguin:2006/12/09(土) 05:50:59 ID:MBLL7Uyo
>>143
開発とかしてる訳でもないし、趣味なんで別にそこまで詳しくなろうとも思わんわ
噂でいいって聞いたxfsを使ってみようかなくらいの感覚だったしね。しかしext3が10分で書き込みが終わるの
に70分掛かってるしメモリも馬鹿喰いで。。イラネ

結局ext3をメタデーターと完全データーの両方をジャーナルするモードにして使用することにしました。
ReiserFSは軽くて早いしよかったけど今後の事を考えるとスムーズに次世代のext4へ移行できる環境
がいいかなと。xfsは相性が悪かったので残念です。

147 :login:Penguin:2006/12/09(土) 10:06:19 ID:XepFnD8l
>>146
なんでそんなに自分自身のバカさ加減を他人に喧伝したいの?

148 :login:Penguin:2006/12/09(土) 10:41:34 ID:XvZbgYpg
>>146
素直にreiserfs使っておいて、スムーズにreiser4に移行しろよって話だわな。むしろその前にzfsが普及する可能性があるが。

149 :login:Penguin:2006/12/09(土) 11:01:59 ID:PRqPU+Ss
Linuxにzfsの移植なんてまともに出来るんか?フルスクラッチで。


150 :login:Penguin:2006/12/09(土) 11:13:49 ID:XvZbgYpg
詳細にドキュメント化すれば何とかなるでしょ

151 :login:Penguin:2006/12/09(土) 11:26:27 ID:OrMFCIvy
SunがGPL化する方がはやいんじゃないの?

152 :login:Penguin:2006/12/09(土) 12:18:02 ID:MBLL7Uyo
>>148
確かにその選択をしようかと思ったのですが結局もっとも無難な方向でしまいました^^;

153 :login:Penguin:2006/12/09(土) 13:13:51 ID:oECGYLlp
それより Sun が ZFS のラインセンスを移植可能なモノにするかなぁ。
あと、ReiserFS ってこれからも続いていくのかなぁ。
と弱気なオレは ext3 でいいや、ってことにしてる。

154 :login:Penguin:2006/12/09(土) 13:20:37 ID:XvZbgYpg
>>153
サン、「OpenSolaris」へのGPL適用も検討中--幹部の発言で明らかに
http://japan.cnet.com/news/ent/story/0,2000056022,20315848,00.htm

可能性は無くは無さそう。
#ってかSecond Lifeって…

155 :login:Penguin:2006/12/09(土) 13:49:40 ID:a073A2ss
CDDLなんて最初からうまくいくわけないって散々言われてたのにな

156 :login:Penguin:2006/12/09(土) 14:42:03 ID:+BMSQsJ6
>>134
いまいちよくわからんのだが俺も nautilus + XFS で信じられない位遅かったな
コピーしようとしたら CPU 占有 & 超低速で笑った。迷うことなく速攻 kill
でも普通に cp したら早かったんで FS じゃなくて GNOMEが悪いんじゃね?

日本語ファイル名ばっかりだったからシェルでいじるのダルかった...

157 :login:Penguin:2006/12/09(土) 15:01:16 ID:xcZ61voz
PCMan File Manager + XFS だけど遅いと感じたことないな。
と思って今Nautilusでコピーしてみた。
めちゃくちゃ遅いんですけど・・・
コピーの速度がPCMan File Managerだと50M/sくらいでNautilusだと3M/sくらいになってる。
CPU使用率はPCMan File Managerだと20%ほどNautilusだと10%ほど。
俺もUbuntuだけど、Ubuntu特有の現象?それともGNOMEかな?
なんにせよNautilusを使わずに他のファイラや端末使えば問題ない。

158 :login:Penguin:2006/12/09(土) 16:35:25 ID:6c2eJaxy
>>126->>132 のファイルコピーってnautilus使っての作業なのか?
普通にcpでの作業を想定したぞ。

>>133で初めてnautilusで出てくるんだが、
cpだと普通の速度で、nautilus使ったら激遅ならnautilusのせいで
fsのせいではないだろ。

159 :login:Penguin:2006/12/09(土) 17:08:13 ID:rWrLJc8b
NautilusはGnomeの癌
今までも、そしてこれからも

160 :login:Penguin:2006/12/09(土) 17:55:39 ID:M+her1pQ
gnomevfsはデザイン上の問題があってデータが壊れることがあった
http://blogs.gnome.org/view/cneumair/2006/01/10/0

gnomevfsは問題多すぎでうんこでファックなので新しいのに変えようぜ
http://mail.gnome.org/archives/gtk-devel-list/2006-September/msg00072.html

gnome,nautilus自体つかってないのでなんとも。

161 :login:Penguin:2006/12/09(土) 19:19:33 ID:5nAPCmxh
nautilus2.16+reiser3.6では遅くならんな

162 :login:Penguin:2006/12/09(土) 20:52:16 ID:xcZ61voz
結論はnautilus+xfsがダメってことでOK?

163 :login:Penguin:2006/12/09(土) 21:01:20 ID:PRqPU+Ss
結論はnautilusがダメってことでOK

164 :login:Penguin:2006/12/09(土) 21:15:29 ID:QVIoEzpT
ダメなのはお前らの脳だと思うんだがなぁ

165 :login:Penguin:2006/12/09(土) 21:18:23 ID:OsYlNHdM
なんだかんだでXFS重いネタは発展したじゃん。
nautilus + xfs で遅くなることを報告し問題を探ろうとした質問者に拍手。


166 :login:Penguin:2006/12/09(土) 21:31:31 ID:QVIoEzpT
( ゚д゚) ・・・
 
(つд⊂)ゴシゴシ
  _, ._
(;゚ Д゚) … 何ひとつ発展してないように見えるが!?

167 :login:Penguin:2006/12/09(土) 21:51:29 ID:6srhV/6+
自分で原因も追求できないようなやつは
素直にext3でも使ってろってこった。

168 :login:Penguin:2006/12/09(土) 22:11:49 ID:1d5W5tst
2.6.17.7から2.6.18.3, 2.6.19に変えたらXFSの大量ファイル削除やコピーが
重くなった気がする。
SATAドライバのせいかもしらんけど。

169 :login:Penguin:2006/12/09(土) 22:14:16 ID:QVIoEzpT
気にするな。

170 :nautilusの人:2006/12/09(土) 23:08:49 ID:MBLL7Uyo
おお! なんか原因らしき物が見えてきましたね。みなさんありがとう。
ちなみに今Reiser4をカーネルに組み込んでコンパイル中です。
メモリとかの設定などもついでに変えてみました。make configの中を見ると確かにLinuxは標準で
ntfsを持っているんですね。デフォルトでMになってないのはWINに対する嫌がらせかと思ってしまったりw
あとはこのカーネルがまともに立ち上がるかです。。。

171 :login:Penguin:2006/12/10(日) 00:35:07 ID:IFH3c9Be
>ntfsを持っているんですね。デフォルトでMになってないのはWINに対する嫌がらせかと思ってしまったりw

バカなのかなぁ・・・

172 :login:Penguin:2006/12/10(日) 00:54:36 ID:CiyFfnIL
>バカなのかなぁ・・・

多分,若くていろいろと経験が足りないだけだと思う。

173 :nautilusの人:2006/12/10(日) 01:13:22 ID:TgXM1Sad
ここの住民はじじいばっかかwwwww

174 :login:Penguin:2006/12/10(日) 01:15:16 ID:ZIVzZTYQ
カーネルこねてるんなら、カーネルのNTFSサポートのHelp読めよ

175 :login:Penguin:2006/12/10(日) 02:52:33 ID:0gb/zk4T
開発もしてないのに趣味でカーネルビルドしたり
ファイルシステム変えたり
奇特な若い衆ですね。

176 :login:Penguin:2006/12/10(日) 03:10:45 ID:/uFKb+GK
>>170
もう二度と湧いてくるな

177 :nautilusの人:2006/12/10(日) 03:46:13 ID:TgXM1Sad
>>171 >>174
しょせん俺は何も知らない馬鹿だよ。でもおまえらの人を見下げたような文章もあまり知性が感じられないぞ
アホタレどもめ
>>176
おまえに言われなくても二度とこねえよw このお子さまランチめ

最後に一言
このスレで色々と情報をくれた方々に、ありがとうございました

178 :login:Penguin:2006/12/10(日) 03:50:27 ID:88+w2rhZ
>>175
んー?それに関しては別に問題ないんじゃない?
学生さんでインストールマニアだったらカーネルビルドとか
気に食わないfs捨てたいから変えるくらいするだろ。

むしろ最近の学生はそれすらできない香具師しか多そうだし、
良い方の奇特な香具師だと思うぞ。

179 :login:Penguin:2006/12/10(日) 09:34:16 ID:jHWNrXu/
そうだそうだ、オプション変えてカーネルのビルドを繰り返すうちに
カーネルの内部構造に興味をもっていくもんなんだ。

てなわけで、ガンガレ>>177

180 :login:Penguin:2006/12/10(日) 10:08:51 ID:CiyFfnIL
まぁ,がんばって欲しいところではあるね。
ただ,他の人が理解の仕方がおかしいと指摘していることに関しては,
もう少し努力する必要があると思うけれど。

181 :login:Penguin:2006/12/10(日) 12:06:52 ID:WasA3VVH
残り少ない今年の目標
 若い奴は生温かく谷底に突き落とせ!

182 :login:Penguin:2006/12/10(日) 13:19:59 ID:XLohVbNm
>>180
努力はしてほしいけどな。
ただ、>>177みたいにキレて捨て台詞吐いて逃げるってのはやめた方がいいな。

183 :login:Penguin:2006/12/10(日) 14:29:45 ID:jHWNrXu/
>>182
今頃の若者にしては、捨て台詞の後に礼をしているあたりが
見所がある。

184 :login:Penguin:2006/12/10(日) 16:35:52 ID:2HNgBmx6
どう見ても精子です。
本当にありがとうございました。


185 :login:Penguin:2006/12/10(日) 17:20:16 ID:sXlQ0bnD
知らないこと・わからないことを公の場で聞けるのは立派
それを見下す連中こそ馬鹿 おまえ達だって知らない時期があったでしょ
わざわざ暴言書く暇があるならどっか参考になるURLでも示す方が生産的。

でもどんな理由があってもキレ台詞はやめたほうがいい。品性が落ちる。

186 :login:Penguin:2006/12/10(日) 17:49:38 ID:TNoYmltu
少なくとも匿名掲示板で何か教えてもらったというのは記憶に無いな。

187 :login:Penguin:2006/12/10(日) 17:56:35 ID:hIevwezh
ググればわかる情報は教えてもらえないだろう
質問されたほうはムカつくもんな

188 :login:Penguin:2006/12/10(日) 20:51:36 ID:/uFKb+GK
>>185
教えてクンを肯定するのもなぁ。

189 :login:Penguin:2006/12/10(日) 21:03:49 ID:b8muUvr3
>>185
罵倒することも立派な教育だよ。 無視するよりはずっと良い。

190 :login:Penguin:2006/12/10(日) 21:26:54 ID:aQAOhBxb
馬鹿ばっか。

191 :login:Penguin:2006/12/10(日) 21:27:47 ID:AaJ/gQWg
と馬鹿が申しております。

192 :login:Penguin:2006/12/11(月) 02:11:53 ID:WQUWzS9F
>>185
>わざわざ暴言書く暇があるならどっか参考になるURLでも示す方が生産的
ということで
っ ttp://www.linux.or.jp/readme.html#tako
いやこっち(も)だな w
っ ttp://www.linux.or.jp/toc_beginners.html

>>178
>むしろ最近の学生はそれすらできない香具師しか多そうだし
今は学生に限らず社会人までそうだもんな。「そんな事聞いて無いからしませんでした」ってばっかり・・・

まあとにかくガンガレ

193 :login:Penguin:2006/12/13(水) 00:48:25 ID:bqgQBo7n
Solaris10 11/06出た。RAID-Z2(RAID6)とホットスペア機能が使えるようになった。

194 :login:Penguin:2006/12/13(水) 18:51:41 ID:b8bVQzXm
はやく移植されないかなー

195 :login:Penguin:2006/12/14(木) 19:38:33 ID:DclqJgck
ext2fsdってどうですか?安定してますか?

196 :login:Penguin:2006/12/15(金) 07:46:57 ID:YAtgT/AF
うん。

197 :login:Penguin:2006/12/16(土) 06:30:03 ID:KNwmu5Y4
サイズの大きなパーティションにファイルシステムのイメージごと dd などでコピーして
その後ファイルシステム自体も成長させられるようなファイルシステムってありますか?
縮小はさらに難しそうだなぁ

198 :login:Penguin:2006/12/16(土) 07:19:02 ID:KNwmu5Y4
うぉ、mdadm で linear なアレイ作って
後でいくつかディスク追加しようと思ったら
--grow は linear では使えないって orz

199 :login:Penguin:2006/12/16(土) 07:32:43 ID:+S1DoSTm
loopbackデバイスを使ってLVMとかできるんじゃねえ?
やったことないし縮小も無理だけど。

200 :login:Penguin:2006/12/16(土) 08:56:25 ID:h5sW2mHZ
linearってなんだっけ?
コンカチネイト(JBOD)だっけ?
それともストライプ(RAID0)?


201 :login:Penguin:2006/12/16(土) 09:49:45 ID:ozfgfRrw
>197
そこまで具体的に言われたら FreeBSD の ufs だって出来る...

Linux の FS も含めてどれだけ実用的・安全に出来るかどうかは
たぶん全然別の問題という気がするけど

202 :login:Penguin:2006/12/16(土) 10:15:07 ID:+S1DoSTm
>>197
スマソ
ddでイメージファイル作って、イメージファイル内のファイルシステムを成長させる話と勘違いしてた。

GNU Partedを使う場合
http://nobumasa-web.hp.infoseek.co.jp/partition/parted/

ファイルシステム付属のユーティリティを使う場合
http://pantora.net/pages/linux/lvm/3/

FreeBSD のufsもgrowfsがある

203 :login:Penguin:2006/12/16(土) 11:48:37 ID:KNwmu5Y4
>>200
madam --cretae --level linear は JBOD っす。
余った小さなディスク(60GB)くらいのがちょこちょこ
集まってくるんで、くっつけて作業用にでも使おうと思って。

>>201-202
ufs ってのは成長させられるんですね。
いままで ext2 ext3 くらいしか使ったこと無かったんで
今から手探りでいろいろ試してみようかと思ってます。
OS は Linux 。何かあってもいいように VMware 上の
Debian か Fedora Core で実験予定。

204 :netadesu:2006/12/16(土) 15:05:21 ID:SIzSeUHT
growだったらできないfsの方が稀じゃないか?
ただ、hot expandできるかどうかは別。

やらないにこしたことないから常用してはないけど、
ext2(3だったかも), reiserfs, xfs ではやったことある。


205 :202:2006/12/16(土) 17:18:02 ID:+S1DoSTm
GNU Partedも現在はufsのリサイズサポートしてるみたい。
http://www.gnu.org/software/parted/manual/html_node/resize.html#resize

growfsのラッパーだろうけど。

206 :login:Penguin:2006/12/16(土) 17:23:46 ID:XtbPeLaZ
ext2/3はpartedよりresize2fsの方が確実
parted、拡張に追いついてきてないし



そして名前も出てこないjfs(-o remount,resize)かわいそす

207 :login:Penguin:2006/12/16(土) 17:26:19 ID:FC6GU6Ut
みんなぶっちゃけ、jfsなんて使ってないんだろ?

208 :202:2006/12/16(土) 18:18:47 ID:+S1DoSTm
>>206
> そして名前も出てこないjfs(-o remount,resize)かわいそす

> ファイルシステム付属のユーティリティを使う場合
> http://pantora.net/pages/linux/lvm/3/

ちゃんとでてるだろw


209 :netadesu:2006/12/16(土) 19:52:23 ID:SIzSeUHT
>>207
トップ3以外はあまり使ってもらえないのが実情だから。

reiser*の開発がBSD訴訟された*BSDみたいに遅延しそうな気配があるから
数年後にはext4,xfs,jfsの3強になってるかもね。zfsも期待。


210 :login:Penguin:2006/12/16(土) 20:05:37 ID:82ULKkhv
>>209
またまた冗談を(AA略
zfs,reizer*,ext*の3強に決まってる。

211 :login:Penguin:2006/12/16(土) 20:13:37 ID:b3Zossa2
zfs(raidz,2)のハード実装ってどれくらいで出てくると思う?
誰かが作ってると思うんだ。
どういう感じのデバイスに見えるのか分からんけど・・・・

212 :login:Penguin:2006/12/16(土) 20:23:39 ID:FC6GU6Ut
CDDLで成功したソフトウェアってないんじゃないの。

オープンソースなのはありがたいけど、CDDL読んだあとにパッチを
コミットしようと考えるボランティアはあんまりいないんじゃない。

jfsはGPLなのにボランティア少なそうだけど。

213 :login:Penguin:2006/12/16(土) 20:53:55 ID:rOPtoKv8
>>212
なので、OpenSolarisのGPL化なんて噂はある。JavaもGPL化って噂だし。

214 :netadesu:2006/12/16(土) 21:44:56 ID:SIzSeUHT
>>213
旦那旦那、噂じゃないですよ。それは去年の話。


215 :login:Penguin:2006/12/16(土) 21:52:53 ID:KoFH3LYy
キリンさんのOS

Nexenta OS
http://www.gnusolaris.org/gswiki

216 :login:Penguin:2006/12/16(土) 21:59:32 ID:qYQjoEYU
>>215
銀河麒麟をもちだしてきたのかと思った。

217 :login:Penguin:2006/12/17(日) 00:23:09 ID:Q2xF4z7Q
http://www.drk7.jp/MT/archives/000932.html

> Server File Cache → Storage の解説によれば、
> 
> ext2 は複数のバグが絡み合って、 結果として同期的書き込みが全く保証されない。
> user data の disk への書き込みは、 write システムコールに対する O_SYNC フラグを付与しても、 fsync システムコールを呼び出しても、
> sync システムコールを呼び出しても、 保証されない。
>  umount によってのみ、dirty page は 100% 反映される。
> と言うことは、 ext3 層が ext2 に Journal を書いてくれと頼んでも、 Journal 記録が disk に書き込まれる保証はない という事を意味する。
> さらには、ext2 は書き込み順序にエレベーターシークアルゴリズム などを用いるので、 Journal ファイルへの > Journal 記録の反映順序保証さえない事になる。
> 
> だそうです。

詳しい人この辺のことどうよ。
ext3のジャーナルはどれくらい信用できる?

218 :login:Penguin:2006/12/17(日) 02:01:49 ID:iXfl1BVU
キチガイの書いた文章を読むとキチガイが伝染るよ!
うんこに触ると手にうんこ付くよ!

                 ハ_ハ
               ('(゚∀゚∩ つくよ!
                ヽ  〈
                 ヽヽ_)

219 :login:Penguin:2006/12/17(日) 02:26:58 ID:Q2xF4z7Q
> Server File Cache → Storage の解説によれば、

http://www.dd.iij4u.or.jp/~okuyamak/Documents/NetworkFileSystem.Tune.4.html
ここの事なんだけど、何のことだかさっぱりわかりませんです。

220 :login:Penguin:2006/12/17(日) 02:29:31 ID:iXfl1BVU
ウンコ臭いリンク貼るのやめてください。
それとも本人ですか?

221 :login:Penguin:2006/12/17(日) 02:31:55 ID:Q2xF4z7Q
本人が、「何のことだかさっぱりわかりませんです。」とか言いますか?
で、2つのリンクともキチガイが書いたと?

222 :login:Penguin:2006/12/17(日) 02:34:53 ID:iXfl1BVU
yes
yes

223 :login:Penguin:2006/12/17(日) 02:37:30 ID:Q2xF4z7Q
そうですか。
少し興味を持ったので貼ってみたんですが、騙された私がアホだということでしょう。

224 :login:Penguin:2006/12/17(日) 05:16:30 ID:RV23LfOh
散々既出のネタだから過去ログでも漁ってこい

225 :223:2006/12/17(日) 07:18:22 ID:Q2xF4z7Q
>>224
過去ログ一応その2から読んだ。(丁寧に読んだのはその2だけ)
ついでに、「何のことだかさっぱりわかりませんです。」と思ったリンク先も読み直した。

まあ、確かにうんざりするくらい語られてるねえ。
後、奥山氏がいわくつきの人物なのもわかった。

で、結局ジャーナルファイルのsyncは保証されてるのかどうかはよくわからなかった。
ジャーナルファイルがvfsレイヤを使わず、独自ルーチンを使ってるって反論もあったけど、
独自ルーチンがsyncを保証してる説明はなかったよ。
Linuxは当初から性能重視で非同期書き込み、*BSDは信頼性重視で同期書き込みを志向してたはず。

どちらが正しくても、正直構わないけどここの住民はもうちっと骨のある反論しろよ。


226 :login:Penguin:2006/12/17(日) 11:15:48 ID:OfbsfsR3
>225
つ ttp://www.drive.ne.jp/iMA/showmdir.pl?FreeBSD-users-jp=2005-06&num=85534&link=200506241542%2ej5OFgYZ05349%40srapc342%2esra%2eco%2ejp

その内容を読み取ってなにが正しいか判断するのはお任せする。


227 :login:Penguin:2006/12/17(日) 11:25:23 ID:hhbkxu9f
また奥なんとかかよ
飽きねえ奴だな

228 :login:Penguin:2006/12/17(日) 12:46:25 ID:23TZod3p
ID:iXfl1BVUのように発狂しているだけの包茎くん。
HIVに感染しやすくなるんだから、とっとと手術しろよ。しかも臭いし。
お前、生きる公害だぞ。

229 :login:Penguin:2006/12/17(日) 13:50:10 ID:iXfl1BVU
>>228
本人キター!

230 :login:Penguin:2006/12/17(日) 14:50:56 ID:edSVj54I
ID:iXfl1BVU はちょっと黙っててくれないかなあ。

231 :login:Penguin:2006/12/17(日) 15:33:19 ID:iXfl1BVU
じゃ黙ってるから存分に有意義な議論をしてくれ

232 :login:Penguin:2006/12/17(日) 15:51:41 ID:gBsLzMH4
つか奥屋マンコのスレでも立ててそっちでやれってかんじー

233 :login:Penguin:2006/12/17(日) 15:58:34 ID:PCiXBd2b
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄」
―――――――――――――‐┬┘
                        |
       ____.____    |
     |        |        |   |
     |        | ∧_∧ |   |
     |        |( ´∀`)つ ミ |
     |        |/ ⊃  ノ |   |
        ̄ ̄ ̄ ̄' ̄ ̄ ̄ ̄    |
                        |  ext3

234 :login:Penguin:2006/12/17(日) 17:54:13 ID:Q2xF4z7Q
>>226
メーリングリスト一応全部読んだ。
議論の余地がないでしょ。
LinuxのsyncはHDDのバッファをフラッシュしない。

235 :login:Penguin:2006/12/17(日) 18:51:54 ID:eRUWixex
そして、FreeBSDでも6以降はフラッシュしない…

236 :login:Penguin:2006/12/17(日) 19:22:58 ID:6nMM/n3x
次の展開はわかっている!
こうだ!



NetBSDマンセー (35歳 会社員)

237 :netadesu:2006/12/17(日) 19:29:46 ID:Df4Nxwhq
BSD vs Linux って考えてみれば UNIX の最下層でどちらが下か
やってるだけなんだよな。

Solaris/AIX/HP-UX/SUPER-UX... とかの世界のファイルシステムってどうなんだろう。


238 :login:Penguin:2006/12/17(日) 20:22:16 ID:7CL4+VjT
NetBSD + LFS最強説

239 :login:Penguin:2006/12/17(日) 21:16:34 ID:xnDjwphy
いずれにせよLinuxのソフトウェアRAIDでは
grow ができないので、あんまりメリットか無い気がする。
LVM を使ったことが無いので外しているかもしれない。

240 :login:Penguin:2006/12/17(日) 23:38:46 ID:BpKCD3FA
>>239
dm,mdは適宜使い分けるべし。どっちを上にも出来るから。

241 :netadesu:2006/12/17(日) 23:39:16 ID:Df4Nxwhq
growさせるつもりならLVM-on-RAIDにして、ディスクを追加するときは
独立したRAID-1/5セットをPVとしてLVMに追加してgrowさせるよ。

見せ方は違っても、これは他のOSでも同じじゃないの?
物理デバイス冗長を取る部分と可変長な論理デバイスを実現する部分は
直行してるはず。


242 :login:Penguin:2006/12/18(月) 01:53:56 ID:5CjTidJ8
めちゃくちゃパフォーマンス悪そうだがw

243 :login:Penguin:2006/12/18(月) 02:05:56 ID:Nty7XqwY
俺もLVMにしてる。

244 :login:Penguin:2006/12/18(月) 02:24:08 ID:BgGwtA55
>>237
SolarisなどはOSのコアな部分ではLinuxや*BSDの二歩も三歩も先に行っているからねぇ。
fsにせよ、I/O周りにせよ、SMPにせよ、スケジューラにせよ、ネットワーク周りにせよ。

>>238
そういえば、最近のLFSはそこそこ安定してきているみたいですな。
ただ、NetBSDのLFSが磐石になる前に、ZFSが各OSにportされそうな雰囲気だけど。
そういえば、LinuxにもgcがないすさまじいLFSがあったな…

>>243
LVMはトラぶったときのことを考えるといやなんだよなぁ。

245 :login:Penguin:2006/12/18(月) 03:11:56 ID:F98nsRY8
>>241
あれ?俺いつのまに書いたっけ?


246 :login:Penguin:2006/12/18(月) 05:49:01 ID:lBfvMR/v
ふむ、md でも JBOD できるけど、grow する事を考えれば
LVM 使えってことですか?そもそもソフトウェアRAIDの枠組みの中で
JBOD できる Linux が変態?

247 :login:Penguin:2006/12/18(月) 07:27:40 ID:oHr+ULas
頭悪そうだね

248 :login:Penguin:2006/12/18(月) 08:14:37 ID:sqlaZvsB
本家HP-UXのように、md(ソフトウェアRAID)とLVMって調和が取れてないから、
組み合わせて使うのはためらうんだよな。

ZFSはソフトウェアRAID、LVM、ファイルシステムのLinuxが弱い部分を一気通貫でカバーしてるからな。


249 :login:Penguin:2006/12/18(月) 08:34:26 ID:etiTNDak
>>248
なんで前半は HP-UX なのに、後半は ZFS?

ZFS みたいに一体化したものは置いとくとして、
Linux の LVM 自体は良くできてると思うけどなあ。数十台、数十TB
使ってるけど、構成情報のバックアップだけ残しておけば、そうトラブル
復旧も難しいわけじゃない。

250 :login:Penguin:2006/12/18(月) 15:13:18 ID:8QMqXAUL
LVMについで一文
ZFSについてでもう一文

251 :login:Penguin:2006/12/18(月) 18:30:49 ID:Y/ed09i4
ファイルシステム変換がうまくいきません…。
誰かお教え下さい。

ファイル システムの種類は FAT32 です。
ドライブ H: の現在のボリューム ラベルを入力してください ******
ボリューム ****** は 2006/12/05 17:26 に作成されました
ボリューム シリアル番号は ...... です
ファイルとフォルダを検査しています...
ファイルとフォルダの検査を完了しました。
ファイル システムのチェックが終了しました。問題は見つかりませんでした。
244,136,352 KB : 全ディスク領域
76,320 KB : 115 個の隠しファイル
26,784 KB : 833 個のフォルダ
69,861,888 KB : 22,810 個のファイル
174,171,328 KB : 使用可能ディスク領域

32,768 バイト : アロケーション ユニット サイズ
7,629,261 個 : 全アロケーション ユニット
5,442,854 個 : 利用可能アロケーション ユニット

ファイル システムの変換に必要なディスク領域を調べています...
全ディスク領域: 244196001 KB
ボリュームの空き領域: 174171328 KB
変換に必要な領域: 347074 KB
基本ファイル システム構造を作成できません
変換に失敗しました。
H: は NTFS に変換されませんでした

252 :login:Penguin:2006/12/18(月) 18:31:51 ID:pj2+GtGf
>>251
Windows は板違い。

PC初心者
http://pc7.2ch.net/pcqa/

253 :251:2006/12/18(月) 18:31:58 ID:Y/ed09i4
すいません
誤爆しました

254 :login:Penguin:2006/12/18(月) 22:50:45 ID:7eT6c4q7
ちょいと、お聞きしますよ。
自宅のメールサーバをPPCにしようかと思ってるんですよ。
で、ファイルシステムの実績を見てたんですがイマイチ分からない。
エンディアンが違ったときの使用実績がわからんのです。
SGI、IBMが作ったxfs、jfsはそのあたり何とかなってそうですがどんなもんでしょう。
非intelアーキテクチャで動かしてる人もみんな大体ext3なんですかね?

ま、壊れても困るのは家族くらいなんでドレでもいいという話はありますが。
興味ひかれてということで。

255 :login:Penguin:2006/12/19(火) 09:53:23 ID:8O8QeZf3
>>254
ユーザが多いのにしておくのが無難ね?
玄箱すれで聞いてみるとか。

256 :login:Penguin:2006/12/19(火) 10:43:37 ID:LR+FoNiH
実際のところ、エンディアンは関係あるのかなあ?
俺はないと思うが。
エンディアンで変わるのはファイルの中身だけじゃねえ?

257 :login:Penguin:2006/12/19(火) 10:52:00 ID:XzW6MizV
file attribute の意味が変わったり
ファイルの大きさが 1600万倍になったりしてもビックリしないの?

258 :login:Penguin:2006/12/19(火) 10:58:10 ID:8O8QeZf3
異なるエンディアン間でディスクを移動したりすると
やばい聞いた。特にextXとか、mdのメタデータとか。

259 :login:Penguin:2006/12/19(火) 12:12:40 ID:JTMTN/tV
>>257
それはVFSレイヤの話でないの?
ファイルシステムに直接依存するのだろうか。

260 :login:Penguin:2006/12/19(火) 12:23:30 ID:JTMTN/tV
それは、ビッグエンディアン環境⇔リトルエンディアン環境を移動させればまずいよなあ。
まさに>257の言う事が起こる。
しかし、そうでない場合に>257が言うようなことが起きればVFSの問題と思うんだが。

261 :login:Penguin:2006/12/19(火) 12:28:02 ID:JTMTN/tV
とここまで書いておいて気がついた。
何も考えずに書き込み、何も考えずに読み出しても同一環境では問題オコラネー。
VFSもファイルシステムも関係ネー。
違うか?

262 :login:Penguin:2006/12/19(火) 13:04:19 ID:TnIoz1+9
>>258
んなことねえよ
ちゃんと考えて設計されてるよ
角度とか

263 :login:Penguin:2006/12/19(火) 13:23:33 ID:8O8QeZf3
>>262
ttp://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/1162.html
うひひ

264 :login:Penguin:2006/12/19(火) 13:31:26 ID:qiS7ynEf
何このレベル低下っぷり?
以前はキチガイも多いがここまで低レベルじゃなかっただろこのスレ。

265 :login:Penguin:2006/12/19(火) 13:57:36 ID:1t2/+nmt
ext3はOKだと言われているが、他は知らん。
SolarisだとUFSはバイトオーダ依存で、ZFSはバイトオーダ非依存。


266 :login:Penguin:2006/12/19(火) 14:21:29 ID:skFd6jjj
ext2をi386と〜ebな環境で使いまわしてるけど、
いまのところ問題は起きてないな。
ただe2fsprogsは全部試していないので、そのへんに
地雷が埋まってるかもしれん。


267 :login:Penguin:2006/12/19(火) 14:30:12 ID:O6QzCkRT
>>264
ツマンネ

268 :login:Penguin:2006/12/19(火) 14:51:31 ID:LBOK3XqF
>>265
今月のSDにZFSの記事があって、
ZFSは書き込みはマシンバイトオーダ、
読み込み時に変換してると書いてあったな。

269 :login:Penguin:2006/12/19(火) 15:52:09 ID:wh6OROKj
>>268
ってことは、ファイルシステムにバイトオーダが記録されてるのかな?
別のマシンにディスク持って行っても使えるけど
バイトオーダが違うマシンに持って行くと動くんだけどパフォーマンスが落ちる、と。
おもしろいかも

>>255
すまね。
ひねくれてるのでext3とjfsで作ってみた。

jfsがどれくらい頑丈か、かな・・・・
取りあえずディスクを直接持って行っての物理的な共有はしないようにします
環境できたらpostmarkでもやってみるよ

270 :login:Penguin:2006/12/19(火) 16:34:14 ID:LBOK3XqF
>>269
全くの推測だけどどっかのビットで判別してるんじゃないかな。
0だとLEとか。

記事ではsparcマシンのHDDをintelマシンに持っていっても読める
と書いてあったが、パフォーマンスに関しては書いてあったか忘れた。
変換のオーバヘッドはほんの少しだろうけどあるだろうな。

271 :login:Penguin:2006/12/19(火) 16:42:59 ID:I6Be52hp
>>269
このスレで大人気の奥山氏曰く
「ついでに言うと、JFSの信頼性のなさも問題があるので、それに修正を当て
ても、『XFSに追いつく』程度でしかない」とのこと。

あくまでもLinuxとFreeBSDとのsync時の挙動の違いについての話の中で
余談としてでてきた話題でソースがないのであれだけど、このスレでも
XFSに比べてJFSって特に信頼性高いとも思えないしメリットないなぁという
のは何度も出てきているね。

272 :login:Penguin:2006/12/19(火) 16:45:46 ID:DJKXWzFE
チキンな俺は常にext3

273 :login:Penguin:2006/12/19(火) 16:48:06 ID:WLeCaQbI
いまんとこlinux用はext3中心に回ってるんでおk

274 :login:Penguin:2006/12/19(火) 17:25:19 ID:JTMTN/tV
普通にupdatedbとかたたくと、ext3遅すぎねえ?
ReiserFSの何倍もかかる。
アクセス時のシーク音は明らかに違う。

275 :login:Penguin:2006/12/19(火) 17:39:09 ID:DJKXWzFE
ReiserFSは作者の動向が怪しい

276 :login:Penguin:2006/12/19(火) 17:44:01 ID:qiS7ynEf
怪しいのは作者が住んでる町の警察の動向だろう

277 :login:Penguin:2006/12/19(火) 17:44:48 ID:5KfKfe1m
あれからどうなった

278 :login:Penguin:2006/12/19(火) 17:44:55 ID:JTMTN/tV
確かにナorz
将来乗り換えが必要になる可能性大

279 :login:Penguin:2006/12/19(火) 18:07:21 ID:JTMTN/tV
ext3って皆が使ってるから何か起こっても豊富な情報がある。
それにツール類もまずはext3を前提に作られてると思う。
使うのに十分な値打ちがあると思う。

でも、ツマラネーんだよな。
ext3使っててこのスレ読んでても楽しみ少なくない?

280 :login:Penguin:2006/12/19(火) 18:10:57 ID:TnIoz1+9
楽しみより安定性

281 :login:Penguin:2006/12/19(火) 18:17:58 ID:JTMTN/tV
まあ無難な選択を否定することは、誰にもできないな。

282 :login:Penguin:2006/12/19(火) 18:18:42 ID:GWNB1OAW
住んでいるまちの警察の動向が怪しいなら
結構長くでてこれないかもね。

283 :login:Penguin:2006/12/19(火) 20:14:25 ID:b8knrZg8
>>280
もっとも、安定性を求めるのならLinuxなんか使うなって話もあるわけで。

284 :login:Penguin:2006/12/19(火) 20:17:30 ID:qiS7ynEf
hahahahahahahahahahhahahahahahahaha

285 :netadesu:2006/12/19(火) 20:37:18 ID:oCGBR2+N
>>270
各ファイルシステムとも4byteのマジックコードを定義してるので
それで判別できる。ただし実際に判別してちゃんと読み書き時に
変換してるかは別。

FSじゃないけど0xCAFEBABEとか0xDEADBEEFとかが有名。

 0xCAFEBABE 0xBEBAFECA 0xBABECAFE 0xFECABEBA

と読んだ時に違いが出るので判定できる・・・んだけど64bitの
足音が近いから変態なアーキテクチャが出たりしたら8byteマジックが
必要となる日も近いかも。

286 :login:Penguin:2006/12/19(火) 20:44:56 ID:WLeCaQbI
>>283
そんな話いつどこで聞いたんだ。捏造するな。

287 :login:Penguin:2006/12/19(火) 20:57:01 ID:azfMKvlf
ID:WLeCaQbI発狂中

288 :login:Penguin:2006/12/19(火) 22:27:06 ID://1HgQEi
sun386i と sun3 の disk の繋ぎかえはダメって話だったな

289 :login:Penguin:2006/12/19(火) 23:12:48 ID:LR+FoNiH
結局のところ、>>260-261が的を射ているんだな。
で、ビッグエンディアン環境⇔リトルエンディアン環境のディスク移動ってLinuxではほとんどないんじゃねえの?
SunとかMacとかなら要望は多いだろうけど。

290 :login:Penguin:2006/12/19(火) 23:40:54 ID:leiixtBd
スラッシュドット ジャパン | LeopardはZFS対応か?
http://slashdot.jp/mac/06/12/19/0314236.shtml
刻はZFSの鼓動を見る。たぶん。
http://blog.ninth-nine.com/diary/20061212.txt

291 :login:Penguin:2006/12/19(火) 23:56:10 ID:LBOK3XqF
>>289
i386 <-> ppc ならありえるレベルだと思う。
というか自分では使っている。

まあalpha,sparcあたりも死んでは無いしな。

292 :login:Penguin:2006/12/20(水) 00:06:07 ID:K8chhcW1
>>291
i386 <-> ppcって
Vineでも使われてるんですか?

293 :login:Penguin:2006/12/20(水) 00:09:26 ID:K8chhcW1
まあディス鳥はどうでもいいけど、実際にディスクつなぎ変えるの?

294 :login:Penguin:2006/12/20(水) 00:19:13 ID:MV22v5Iu
PPCはNAS使ってる一部の勘違いさん御用達。

295 :login:Penguin:2006/12/20(水) 07:45:13 ID:yU/fzyFw
>>285
> 各ファイルシステムとも4byteのマジックコードを定義してるので
ソース希望

各ファイルシステムで定義するというのはOSのデザインがおかしいと思う
VFSで定義して、各ファイルシステムで実装というのがあるべき姿と思うんだが

296 :login:Penguin:2006/12/20(水) 07:56:57 ID:yU/fzyFw
というかパーティションテーブルでも同じ問題は起こる
ここを読めないとファイルシステムも読めない
つまり、ファイルシステムを読む段階ではKernelはバイトオーダーを知っていないといけない

こういう問題もあると思うんだが

297 :login:Penguin:2006/12/20(水) 08:14:22 ID:NEgx20b5
そういえば玄箱とかもPPCだっけ。

298 :login:Penguin:2006/12/20(水) 10:42:29 ID:TN7cgs5A
>つまり、ファイルシステムを読む段階ではKernelはバイトオーダーを知っていないといけない
linux/fs/* を見ると le32_to_cpu とか be32_to_cpu とかかいてある。
ほとんどはLEだけど、メジャーどこだとxfsがBEだな。


299 :login:Penguin:2006/12/20(水) 10:53:47 ID:biQx0lWY
>>295
スマソ。全部がというつもりではなくて、fsの多くは独自に
マジックコードを持ってるというつもりで書いた。OS/VFSとかが
マジックがないとダメと規定してるわけではないです。

300 :login:Penguin:2006/12/20(水) 11:16:07 ID:yU/fzyFw
>>298
> linux/fs/* を見ると le32_to_cpu とか be32_to_cpu とかかいてある。

何か勘違いしてるみたいだけど、もう一度言いますよ
パーティションテーブルはファイルシステムを使わず直接ディスクに書き込んである。
ファイルシステムが読めてるって事は、その前に既にバイトオーダーを正しく読んでいるって事が言いたいんですが。

301 :login:Penguin:2006/12/20(水) 15:42:40 ID:CiR8D7Mp
>>292
Vineは使っていない。

>>300
基本的かもしれないが質問。
パーティションテーブルに書くときのバイトオーダはnative?

302 :300:2006/12/20(水) 15:49:05 ID:yU/fzyFw
>>301
> パーティションテーブルに書くときのバイトオーダはnative?

多分そう言われるだろうなと思った。
まあ、>>300の内容は当然そう思っているから。
詳しい人よろしく頼む。

303 :300:2006/12/20(水) 15:59:29 ID:yU/fzyFw
1つ忘れてた。
x86の場合はネイティブだったと思う。
ちょっとサイト探してみる。

304 :login:Penguin:2006/12/20(水) 15:59:35 ID:3ugUm6GB
パーティションテーブルって一口に言っても

305 :300:2006/12/20(水) 16:10:54 ID:yU/fzyFw
http://www.ata-atapi.com/hiwdos.htm
これMS-DOSのブートセクタ。
当然FDだけど。
バイナリエディタでちゃんとアスキー文字が読めているので、バイトオーダはnativeなはず。
まあ、パーティションテーブルだけ反対とか、HDがFDと違う方法を使うとかありえない訳じゃない。
あくまで参考。

306 :300:2006/12/20(水) 16:56:18 ID:yU/fzyFw
HDの場合
http://www.ata-atapi.com/hiwtab.htm#T2
01 01 00が第一パーティションのスタートCHS

http://www.ata-atapi.com/hiwtab.htm#T7
実際のパーティションは先頭セクタがMBRなのでCHS=0,1,1から始まる。

01 01 00が0,1,1を表しているからリトルエンディアン。
x86の場合はネイティブ。

ビッグエンディアンの場合がわからない...

307 :login:Penguin:2006/12/20(水) 17:40:47 ID:iqnu0UKk
>>306
さあ、bigなマシンを調達してくるんだ。

308 :login:Penguin:2006/12/20(水) 17:42:33 ID:fcZO1G6Z
そこでqemuですよ

309 :300:2006/12/20(水) 17:52:46 ID:yU/fzyFw
>>308
サンクス

310 :300:2006/12/20(水) 22:52:54 ID:yU/fzyFw
誰か技量のある人、ビッグエンディアンの検証頼む。
俺もやるけど、簡単じゃない。
パーティションテーブルの仕様もよくわからない。
Qemuもまだ動いてるだけだ。

311 :300:2006/12/20(水) 22:59:15 ID:yU/fzyFw
多分Sparcの方が資料は多い。
パーティションテーブルは先頭セクタでBSD流のスライスが書いてある。
でも、それ以上の資料が無い。

312 :login:Penguin:2006/12/20(水) 23:13:46 ID:npYLopAO
XFSはビッグエンディアンのマシンとリトルエンディアンのマシンではジャーナルログの互換性が無いからxfs_repair -Lでログを消す必要があるとドキュメントに書いてある。

元々はIRIXに接続されていたストレージをAltixに接続するためだったんだけどね

313 :login:Penguin:2006/12/21(木) 00:40:44 ID:LN3BUO6p
zfs importってやるとSPARCで作成したZFSファイルシステムをx64のマシンで
使えるようになるんだってさ。

314 :login:Penguin:2006/12/21(木) 13:11:34 ID:1QKYJ/dy
伝統的な dump/restore でのバックアップを
MySQL などの RDBMS が動いているマシンで
行ううえでの問題点は何でしょうか?

データベースのファイルは随時更新されているので
dump/restore ではまったく意味がないのでしょうか?

315 :login:Penguin:2006/12/21(木) 13:46:14 ID:5fo5L+zb
mysqlのバックアップをわざわざdump/restoreで行う必要はないだろう。
tarなどのファイル単位バックアップでOK。

>データベースのファイルは随時更新されているので
DBのバックアップはDBを止めて行うのが基本。
dump/restoreにしろ、tarにしろDBを止めないと整合性のとれた状態でのバックアップは不可能。
要件的に止められない場合に、DBMSに用意されているオンラインバックアップなどを検討する。


316 :login:Penguin:2006/12/21(木) 14:39:14 ID:+wTFdS6A
>>314
> データベースのファイルは随時更新されているので
> dump/restore ではまったく意味がないのでしょうか?

http://dev.mysql.com/doc/refman/4.1/ja/mysqldump.html
RDBMSの設計者もバカではないから、随時更新されている程度の事はわかってるよ。

-F, --flush-logs
ダンプを開始する前に、MySQL サーバ内のログファイルをフラッシュする。
注意: このオプションを --all-databases(または -A)オプションと組み合わせて使用した場合、
ログは各データベースのダンプごとにフラッシュされる。

-l, --lock-tables.
ダンプを開始する前にすべてのテーブルをロックする。
テーブルは READ LOCAL でロックされ、
MyISAM テーブルの場合は同時挿入が可能になる。
注意: 複数のデータベースをダンプする場合、--lock-tables は各データベースを個別にロックする。
したがって、このオプションを使用した場合、
データベース間でのテーブルの論理整合性は保証されない。
異なるデータベースのテーブルは、
完全に異なる状態でダンプされる可能性がある。

更新中なのが、前提なのがよくわかるだろう。
実際のところどうしたらいいかは、経験が豊富な人間に聞くしかない。

このスレで質問しても大した事は聞けないよ。
DBの板で質問するべき。

317 :login:Penguin:2006/12/21(木) 14:49:40 ID:wTdtL7fh
dump違い

318 :login:Penguin:2006/12/21(木) 14:59:03 ID:+wTFdS6A
MySQLは更新関係にはやはり少し弱い。
Oracleでバックアップコマンドを発行すると、全データベースがロックされ整合性が保証される。

319 :login:Penguin:2006/12/21(木) 15:12:58 ID:+wTFdS6A
http://dev.mysql.com/doc/refman/4.1/ja/backup.html
こっちの方が基本かも。

こちらもちゃんと、更新中であることを前提に書かれている。

320 :login:Penguin:2006/12/21(木) 16:55:40 ID:5fo5L+zb
>Oracleでバックアップコマンドを発行すると、全データベースがロックされ整合性が保証される。
思いっきり間違い。


321 :login:Penguin:2006/12/21(木) 17:23:46 ID:+wTFdS6A
>>314
> 伝統的な dump/restore でのバックアップを
マジ勘違いすまそ

>>320
> 思いっきり間違い。
確かに間違ってますハイ
漏れの場合は表領域デフォルトしか使わなかったので、全データベースのロックもできたけどこれはレアケース

322 :login:Penguin:2006/12/21(木) 17:29:36 ID:WSqxjtJx
>>316
そりゃDBのダンプやん。スレ違いってことが認識できない知能の持ち主の314が
言っているのはfsのdump/restoreでそ。

>>318-320
スレ違いだから、知能障害者の314は放置してもう止めませう。

323 :login:Penguin:2006/12/21(木) 19:19:12 ID:gemQUBxV
>>321
全データベースか、特定表領域かの違いではない。
ロックしてしまったら、サービス継続上の問題になる。

ブロックの変更情報がREDOログに書き込まれるようになり、
表領域がホットバックアップ可能状態になるってことだと思う。

324 :login:Penguin:2006/12/21(木) 19:50:34 ID:5fo5L+zb
話を少し戻すと、DBMSなどのバックアップを
ストレージの3rdミラー(TimeFinderやMRCFなど)を使用することを想定すると、
「Linuxのsyncコマンドでは同期の保証がされない?」ってのは少し気になる問題ではある。
通常、3rdミラーバックアップは、本番機側でsyncを掛けた直後にミラーをスプリットするので、
スプリットされたボリュームのファイルシステムがきちんと整合性取れるのかどうか、ちと不安。
いままで、UnixとWindowsでしか、3rdミラーを使ったシステムを手がけたことがないから、
Linuxリプレイスが基幹系に及んできたらどうなるんだろうか。


325 :login:Penguin:2006/12/21(木) 19:53:34 ID:4grny1OI
またsyncコマンドか
奥なんとかさん、出番ですよ。

326 :login:Penguin:2006/12/21(木) 20:02:32 ID:BadC1Qip
>>325
包茎くん乙
もう二度と湧いて出てこないでね。臭いんで。

327 :login:Penguin:2006/12/21(木) 20:56:54 ID:eQeBXR6E
>>324
> Linuxリプレイスが基幹系に及んできたらどうなるんだろうか。

東証と富士通は Itanium+Linux で行くらしいよ。取引システムの
処理能力がさんざ問題にされたから、そちらを重視なんだろうけど。
http://itpro.nikkeibp.co.jp/article/NEWS/20061219/257264/

328 :login:Penguin:2006/12/21(木) 21:03:57 ID:WbIkO1iK
>>324
> 「Linuxのsyncコマンドでは同期の保証がされない?」ってのは少し気になる問題ではある。

Oracleもこの事の真偽ぐらいは当然知っていると思うから、
もし保証されないのであれば、放置はしていないと思う。
umountで同期できるんだから、同期できないはずはないと思う。
rawデバイス使用時の問題も、含めて。

329 :login:Penguin:2006/12/22(金) 16:04:30 ID:WqL6S9ur
妻の殺害容疑で勾留中のHans Reiser、Namesysを売却方針
http://slashdot.jp/linux/article.pl?sid=06/12/22/0642220&from=rss

330 :login:Penguin:2006/12/22(金) 16:13:04 ID:DsPvjvvV
これはもうだめかもしれんね

331 :login:Penguin:2006/12/22(金) 16:36:02 ID:/iCqG6bS
ReiserFSのためにはむしろいいことかもよ。
彼は優秀な技術者だけど、トラブルメーカーだった。

332 :login:Penguin:2006/12/22(金) 17:42:56 ID:/1j0azIV
天才が抜けた穴が簡単に埋まるとは思えんがな。


333 :login:Penguin:2006/12/22(金) 19:00:59 ID:Co7/GRNn
無実を証明するからだれか金を援助してくれ。

一応形式的にだが会社をやるよ。

無実を証明したらまた俺が開発してやるよ。

魅力的なプランだろ?


こんな感じだと思う。





















開発するのはアナルだけど。

334 :login:Penguin:2006/12/22(金) 19:03:52 ID:opUYRnYx
>>333
(;´Д`)ハァハァ

335 :login:Penguin:2006/12/22(金) 22:41:01 ID:2mRPP6sE
話ぶった切って悪いんだけど
分散ファイルシステムの話題はここでおk?それとも別の場所あるのかしら。

336 :login:Penguin:2006/12/22(金) 22:43:42 ID:LHAWvpAd
>>335
ここでやっちゃっていいんじゃない?

337 :login:Penguin:2006/12/22(金) 22:51:33 ID:/iCqG6bS
> 天才が抜けた穴が簡単に埋まるとは思えんがな。

Reiser4はもう基本はできてるだろう。
後は若いPGの仕事でしょ。

Reiser5以降の事は知らない。
これは彼が捕まっていなくてもわからないし、会社を売ってなくてもわからない。

338 :login:Penguin:2006/12/22(金) 23:32:19 ID:2mRPP6sE
ここでいいか。ではとりあえず・・。

分散ファイルシステムにはAFS(OpenAFS,Arla),Coda,InterMezzoとあるみたいなんだけど,

現状では機能面だとこうで
InterMezzo > Coda > AFS

安定性でみるとこう
AFS > Coda > InterMezzo

こんなんであってる?

あと,NFSv4とかも比較にいれたほうがいいんだろうか。

339 :login:Penguin:2006/12/23(土) 01:59:13 ID:v667gEsO
>>338
Cleversafe は?

340 :login:Penguin:2006/12/23(土) 02:20:21 ID:lNb3tcYl
LFSすげーな
4倍以上はやい

NetBSD-current i386

LFS
time tar zxf ~/pkgsrc-2006Q3.tar.gz -C /opt
tar zxf ~/pkgsrc-2006Q3.tar.gz -C /opt 2.06s user 17.66s system 86% cpu 22.773 total

FFS
time tar zxf ~/pkgsrc-2006Q3.tar.gz -C /opt
tar zxf ~/pkgsrc-2006Q3.tar.gz -C /opt 1.94s user 25.83s system 26% cpu 1:43.08 total

341 :login:Penguin:2006/12/23(土) 10:07:11 ID:pzaVswcy
未だに、NFSv3をUDPで使ってます。

342 :login:Penguin:2006/12/23(土) 10:43:55 ID:yHT154ws
UDPはUDPでメリット無いのかな?
負荷分散とかしやすそうなイメージがある(イメージだけで裏は取ってない)。

343 :login:Penguin:2006/12/23(土) 11:09:44 ID:Z2SBvvTY
UDPだから、転送速度が上がるとかw
これもあてずっぽう。


344 :login:Penguin:2006/12/23(土) 11:54:29 ID:/zNuBneV
>>339

Cleversafeって実用に耐えるの?

345 :login:Penguin:2006/12/23(土) 21:55:41 ID:MNgpS4hJ
メリットがあるから UDP 使ってた訳だが

346 :login:Penguin:2006/12/24(日) 12:25:32 ID:QbyLMMQt
>>340
softupdateは効かせてある?
それとuser timeに違いがあるのが気になる。同じになるはず。

347 :login:Penguin:2006/12/24(日) 12:28:30 ID:QbyLMMQt
UDPだとTCPをおしのけて通信できる
でもGbEを使いきろうとするとTCPのような細かい制御が必要。


348 :login:Penguin:2006/12/24(日) 15:03:41 ID:VUeVRThv
>でもGbEを使いきろうとするとTCPのような細かい制御が必要。

ォィォィ

349 :login:Penguin:2006/12/24(日) 15:05:47 ID:VUuQmegh
>>347
> でもGbEを使いきろうとするとTCPのような細かい制御が必要。

ウソつくな。

350 :login:Penguin:2006/12/24(日) 15:17:50 ID:lyOxSAlM
使いきりたいならUDP一択だろ

351 :300:2006/12/24(日) 15:24:13 ID:xYVNmyrQ
ちわ。
お久しぶりです。

ビッグエンディアンの検証ですが、途中で止まっています。
QemuにPPC版Debianのインスコまでは終わりましたが、アップルパーティションマップの仕様が全く見つからず。
仕方がないので、カーネルソースの中を探していて面白いものを見つけました。


352 :300:2006/12/24(日) 15:25:54 ID:xYVNmyrQ
linux/fs/partitions/mac.h
struct mac_partition {
__be16signature;/* expected to be MAC_PARTITION_MAGIC */
__be16res1;
__be32map_count;/* # blocks in partition map */
__be32start_block;/* absolute starting block # of partition */
__be32block_count;/* number of blocks in partition */
charname[32];/* partition name */
chartype[32];/* string type description */
__be32data_start;/* rel block # of first data block */
__be32data_count;/* number of data blocks */
__be32status;/* partition status bits */
__be32boot_start;
__be32boot_size;
__be32boot_load;
__be32boot_load2;
__be32boot_entry;
__be32boot_entry2;
__be32boot_cksum;
charprocessor[16];/* identifies ISA of boot */
/* there is more stuff after this that we don't need */
};

353 :300:2006/12/24(日) 15:28:25 ID:xYVNmyrQ
linux/fs/partitions/mac.h
#define MAC_PARTITION_MAGIC0x504d


354 :300:2006/12/24(日) 15:29:44 ID:xYVNmyrQ
linux/fs/partitions/mac.c
if (be16_to_cpu(part->signature) != MAC_PARTITION_MAGIC) {
put_dev_sector(sect);
return 0;/* not a MacOS disk */
}

355 :300:2006/12/24(日) 15:38:08 ID:xYVNmyrQ
ちょっと、読みづらくてすまそ。
>>352
__be16signature;/* expected to be MAC_PARTITION_MAGIC */

__be16 signature; /* expected to be MAC_PARTITION_MAGIC */
がコピペでつぶれてしまった。

これってマジックバイトがパーティションテーブルに書き込まれているように思えるんだけど。
それなら、fsが読む事と、パーティションテーブルを読むことの後先のつじつまが合うんじゃね?

後、アップルパーティションマップの仕様を知っている人は情報を希望。

356 :300:2006/12/24(日) 15:51:34 ID:xYVNmyrQ
すまそ。
>>353
#define MAC_PARTITION_MAGIC0x504d

#define MAC_PARTITION_MAGIC 0x504d
がつぶれたもの。

ついでだけど、>>354
if (be16_to_cpu(part->signature) != MAC_PARTITION_MAGIC) {
これだとIntel Macは読めない?

357 :300:2006/12/24(日) 16:29:15 ID:xYVNmyrQ
マジックバイトの話よりこちらの方が重要かな。

>>352を見るとデータはほとんど __be16 か __be32 で渡されている。
マックのパーティションを読む場合に限ればパーティションテーブルの読み込みは、
ビッグエンディアンの決めうちで行われているように見える。


358 :300:2006/12/24(日) 20:12:13 ID:xYVNmyrQ
その他
fs/partitions/msdos.h
#define MSDOS_LABEL_MAGIC 0xAA55

fs/partitions/sgi.h
#define SGI_LABEL_MAGIC 0x0be5a941

fs/partitions/sun.h
#define SUN_LABEL_MAGIC 0xDABE

359 :300:2006/12/25(月) 21:38:37 ID:u5v64fWw
今日も連投マジすまそ。
アップルパーティションマップの仕様を見つけた。
http://developer.apple.com/documentation/mac/Devices/Devices-121.html#MARKER-2-27
内容はほぼ>>352と同じ。

対象ディス鳥のインスコは
http://www.ne.jp/asahi/open/gallery/qemuonwin/qowdebianppc/qowdebianppc.htm
ここを参考に行った。

以下、検証資料を載せる。

360 :300:2006/12/25(月) 21:40:28 ID:u5v64fWw
f-disk -l /dev/hda

/dev/hda
# type name length base ( size ) system
/dev/hda1 Apple_partition_map Apple 63 @ 1 ( 31.5k) Partition map
/dev/hda2 Apple_Bootstrap untitled 1954 @ 64 (977.0k) NewWorld bootblock
/dev/hda3 Apple_UNIX_SVR2 untitled 3941407 @ 2018 ( 1.9G) Linux native
/dev/hda4 Apple_UNIX_SVR2 swap 250879 @ 3943425 (122.5M) Linux swap

Block size=512, Number of Blocks=4194304
DeviceType=0x0, DeviceId=0x0

361 :300:2006/12/25(月) 21:44:48 ID:u5v64fWw
dd if=/dev/hda of=part.map bs=512 skip=1 count=63
hexdump part.map > part.txt

0000000 504d 0000 0000 0004 0000 0001 0000 003f
0000010 4170 706c 6500 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000030 4170 706c 655f 7061 7274 6974 696f 6e5f
0000040 6d61 7000 0000 0000 0000 0000 0000 0000
0000050 0000 0000 0000 003f 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200 504d 0000 0000 0004 0000 0040 0000 07a2
0000210 756e 7469 746c 6564 0000 0000 0000 0000
0000220 0000 0000 0000 0000 0000 0000 0000 0000
0000230 4170 706c 655f 426f 6f74 7374 7261 7000
0000240 0000 0000 0000 0000 0000 0000 0000 0000
0000250 0000 0000 0000 07a2 0000 0033 0000 0000
0000260 0000 0000 0000 0000 0000 0000 0000 0000

362 :300:2006/12/25(月) 21:45:28 ID:u5v64fWw
続き

*
0000400 504d 0000 0000 0004 0000 07e2 003c 241f
0000410 756e 7469 746c 6564 0000 0000 0000 0000
0000420 0000 0000 0000 0000 0000 0000 0000 0000
0000430 4170 706c 655f 554e 4958 5f53 5652 3200
0000440 0000 0000 0000 0000 0000 0000 0000 0000
0000450 0000 0000 003c 241f 0000 0033 0000 0000
0000460 0000 0000 0000 0000 0000 0000 0000 0000
*
0000600 504d 0000 0000 0004 003c 2c01 0003 d3ff
0000610 7377 6170 0000 0000 0000 0000 0000 0000
0000620 0000 0000 0000 0000 0000 0000 0000 0000
0000630 4170 706c 655f 554e 4958 5f53 5652 3200
0000640 0000 0000 0000 0000 0000 0000 0000 0000
0000650 0000 0000 0003 d3ff 0000 0033 0000 0000
0000660 0000 0000 0000 0000 0000 0000 0000 0000
*
0007e00

363 :300:2006/12/25(月) 21:48:02 ID:u5v64fWw
0000000-0000060の解析

--------Sig--Pad--MapBlkCnt-PartStart-PartBlkCnt
0000000 504d 0000 0000 0004 0000 0001 0000 003f
--------PartName
0000010 4170 706c 6500 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
--------ParType
0000030 4170 706c 655f 7061 7274 6974 696f 6e5f
0000040 6d61 7000 0000 0000 0000 0000 0000 0000
--------DataStart-DataCnt--PartStatus-BootStart
0000050 0000 0000 0000 003f 0000 0000 0000 0000
--------BootSize--BootAddr--BootAddr2-BootEntry
0000060 0000 0000 0000 0000 0000 0000 0000 0000

364 :300:2006/12/25(月) 21:49:58 ID:u5v64fWw
以上、PPCの場合もネイティブで間違いないと思う。

もう一度謝ります。
連投すまそ。

365 :login:Penguin:2006/12/25(月) 21:53:17 ID:A+i14brz
さてここで>>300に問題です。
macパーティションの上にext3ファイルシステムを作った場合
どうなるでしょうか?

366 :300:2006/12/25(月) 22:02:09 ID:u5v64fWw
誤り訂正
アップルパーティションマップの仕様のリンク
http://developer.apple.com/documentation/mac/Devices/Devices-121.html#MARKER-9-41

f-disk -l /dev/hda → mac-fdisk -l /dev/hda

>>365
どうなるって、とり方次第でどうにでもとれて意味がよくわからん。
現状は/dev/hda3がext3でマウントされていて、読み書きできてる。
確認不足な点があるなら、追加するよ。

367 :300:2006/12/25(月) 22:10:13 ID:u5v64fWw
もう一度誤り訂正
リンク先は>>359が正しかったorz
マジ申し訳ない。

368 :login:Penguin:2006/12/25(月) 22:16:50 ID:xhvW4o8W
謝りすぎすよw

369 :login:Penguin:2006/12/28(木) 20:16:52 ID:11msnvQ0
http://www.atmarkit.co.jp/flinux/rensai/watch2006/watch12a.html

370 :login:Penguin:2007/01/04(木) 23:31:25 ID:krLFR/+F
Linux: Chasing Down Data Corruption
http://kerneltrap.org/node/7517

Linux: Data Corruption Bug Fixed
http://kerneltrap.org/node/7518

371 :login:Penguin:2007/01/05(金) 23:50:17 ID:9EtcSPvI
gfs興味あるけど、資料少ないなー


372 :login:Penguin:2007/01/06(土) 09:56:21 ID:RHHwlQBc
GFS使ったことあるけど、Maildir形式のメールサーバ×4台に使ったら、
ファイルアクセスが遅すぎて使い物にならなかった。
大容量ファイル向きだわ。

GFS2でどこまで進化してるのに興味あるな。

373 :login:Penguin:2007/01/06(土) 12:01:58 ID:iH08ipQn
使ったことあるならちょっと聞かせてくれ

gfsって、LVMで分割したブロックを他のPCに持って行ってネットワーク経由でアクセスするって考え方でいいんだよな?
(もちろん、冗長化とかでA+AとかA+B+P+Qとかのモデルを取る場合もあるだろうが)

で、LVMってのは、MMUのディスク領域版だよな?
ブロックに分割した領域が、セクタアドレスの再配置を伴って、見かけ一続きのブロック領域としてファイルシステムに提供されるという


なんか根本的に間違ってるかな


374 :login:Penguin:2007/01/07(日) 12:14:00 ID:kV7nDToe
>>373
セットアップ人任せだったし、結構前だから、もうあまり覚えてないなー。

でもファイル読み書きはSANや共有SCSIで読み書きして、
ファイルロックを専用のネットワークでやるんじゃなかったっけ?
クラスタ組んでる内の1台がロック管理用のサーバになって、
他のホストがそのクライアントみたいな。

で、LinuxのLVMって、まだSistina GFS時代の頃にSistina社が
オープンソースで提供したものだったから、
LVMもGFSも管理方法が似てるとかだったような…。

昔はググってもほとんど情報なかったけど、今はググれば情報あるんじゃない?

375 :login:Penguin:2007/01/09(火) 01:43:47 ID:1r/HKlFu
鯖運用するのにFSを何にするのかついつい迷ってしまう。

面倒だから ext3 でいいよね?

376 :login:Penguin:2007/01/09(火) 07:37:31 ID:pFKWUuBq
ファイルがぶち壊れるの、fsのせいかと思ったら、原因はmmap()だったのか…
ttp://kerneltrap.org/?q=node/7518

377 :login:Penguin:2007/01/09(火) 08:09:00 ID:8ySvgupC
こんどはgetdentsが遅いって話になってるな。

378 :login:Penguin:2007/01/13(土) 00:17:35 ID:hhd3ra9J
ジャーナリングファイルシステムが保証するのはメタデータだけらしいですが、
逆にいうとタイムスタンプとかファイルサイズのメタデータが更新されてれば
ファイルの中身は正しく更新されたと考えていいんでしょうか?


379 :login:Penguin:2007/01/13(土) 00:18:27 ID:/hTyXuuv
んなわけない

380 :login:Penguin:2007/01/13(土) 08:50:01 ID:LPgOApau
メタデータの何を保証してると思ってるんだ?

381 :login:Penguin:2007/01/13(土) 13:50:32 ID:7SZBdiSI
保証されるのはメタデータの一貫性じゃね?
データそのものはロストしてもファイルシステムの
健康は損なわれないってことでしょ。

382 :login:Penguin:2007/01/13(土) 14:40:37 ID:/ysw0X03
希望と中途半端な理解がごたまぜになった妄想

383 :login:Penguin:2007/01/14(日) 11:07:16 ID:NA5ZaSYQ
chattr コマンドでは dump コマンドによるバックアップ対象に
含めるか否かなどのフラグを操作することができますが、
これらのアトリビュートは ext2/3 特有のフラグです。

xfs や jfs でも同様のアトリビュートの仕組みはあるのでしょうか?

384 :login:Penguin:2007/01/17(水) 10:59:30 ID:XCRonxTk
>>217

古いネタになりますが..

ext3におけるジャーナル情報の記録はJournaling Block Device Layerを
通して行なわれるのであって、Generic Block I/O Layerが用いられるわ
けではないため、リクエストのソーティングなどは行なわれないのでは
ないでしょうか?

385 :login:Penguin:2007/01/17(水) 11:29:42 ID:83gvpb7N
>>382
つまりlost+foundにバックアップを取っておけば
いざというとき幸せになれるということですね?
いい意味で

386 :login:Penguin:2007/01/17(水) 12:45:07 ID:wR6IvIw/
>>384
今は奥山はジャーナリングの不整合っていうのは取り下げていたような気が。

387 :login:Penguin:2007/01/17(水) 13:20:07 ID:NH1vWgwK
>>386
ソース希望

388 :login:Penguin:2007/01/17(水) 16:06:16 ID:wR6IvIw/
「書き込み順序にエレベーターシークアルゴリズム などを用いるので、
Journal ファイルへの > Journal 記録の反映順序保証さえない」というのは
最近言わなくなって、その前の「sync システムコールを呼び出しても、
保証されない」というのを声高に主張するようになっているんだったかな。

syncしても書き込まれなのは事実だし。

389 :login:Penguin:2007/01/17(水) 16:07:15 ID:wR6IvIw/
あ、syncしても書き込まれないから、ジャーナリング不整合になるという結論は変化なしか。

390 :login:Penguin:2007/01/17(水) 16:11:06 ID:dKhI4BNe
で、その結論は正しいの?

391 :login:Penguin:2007/01/17(水) 16:19:09 ID:l/++G+GY
奥なんとかさんに聞いとけ

392 :login:Penguin:2007/01/17(水) 16:36:28 ID:XCRonxTk
最近のXFSはデータを準備してからメタデータを書くという噂を聞いたのだけど
ホント?

393 :login:Penguin:2007/01/17(水) 18:07:01 ID:BxDmthED
ext3のデフォと同じじゃん

394 :login:Penguin:2007/01/17(水) 21:49:32 ID:5iSAbmWu
BSDのsoftupdateもヤバくなるから取り下げたんじゃないのん?

395 :login:Penguin:2007/01/17(水) 22:28:40 ID:+AGvt5ET
>>394
ディスク側に持ってるキャッシュフラッシュのタイミングが気にいらん
ってな、話だっけ?


396 :login:Penguin:2007/01/18(木) 01:21:11 ID:QSNRktCd
>>395
あと、FreeBSD 5.x以降ではLinux同様syncしてもflushされないのがわかったのもある

397 :login:Penguin:2007/01/18(木) 02:01:10 ID:jUaHNsmy
>>395
> タイミングが気にいらん

そういう話じゃないだろう

ジャーナルに書き込んだがディスクはまだフラッシュしていない
この状態でクラッシュすると、OSはジャーナルを書き込んだと思っているが実際には書き込まれていない

398 :397:2007/01/18(木) 02:03:10 ID:jUaHNsmy
あ、すまん
>395はソフトアップデートの話だったな
スルーしてくれ

399 :login:Penguin:2007/01/18(木) 02:13:17 ID:4qrnvGep
キチガイって伝染するんだな

400 :login:Penguin:2007/01/18(木) 10:40:41 ID:vfB3lZBF
400

うん


401 :login:Penguin:2007/01/18(木) 21:07:25 ID:jUaHNsmy
ついでだが、>397の状態でも常に問題が起こらないとする
そうすると、ジャーナルは無用の長物だということにならないか?

402 :login:Penguin:2007/01/18(木) 22:08:12 ID:fQv5Q68V
問題では歩けど解決策が...ってことだろ

403 :login:Penguin:2007/01/19(金) 02:41:03 ID:6XfomkSC
ヒント:再起動


404 :login:Penguin:2007/01/19(金) 12:31:32 ID:T0ADJeSd
まさに伝家の宝刀

405 :login:Penguin:2007/01/19(金) 20:39:33 ID:4t6qqCPq
ジャーナル破損→再起動→ファイルシステム破損
>>403-404

本当にどうも有難うございました

406 :login:Penguin:2007/01/20(土) 11:26:20 ID:UaLVa0QY
壊れるのは書き込みの順序が原因で、syncしないことは別問題

407 :login:Penguin:2007/01/20(土) 11:35:29 ID:gfquQKqH
先生、質問!
1.書き込みの順序の問題が起こっているのはなぜですか?
2.syncしないことで起こる別問題って何ですか?

408 :login:Penguin:2007/01/20(土) 12:10:54 ID:KTOxmzQl
2は、データ自体が不正になってしまうことだな。
チェックポイント自体は正常に通過したけど、実際にデータが書き込まれていないってことだ。
チェックポイントを正常に通過しているから、ファイルシステム自体が壊れているわけではない。

これは、パフォーマンス上は有利であるが、非常に深刻な問題をもたらすことがある。

1は、媒体エラーによってもたらされるものだろう。
ジャーナルの再作成、fsckが必要になる。
lost+foundに前回のチェックポイント以降の更新データが保存される。


409 :login:Penguin:2007/01/20(土) 12:17:24 ID:gfquQKqH
返事がないようなので、もうひとつ
3.自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか?

410 :login:Penguin:2007/01/20(土) 13:45:07 ID:gfquQKqH
返事ぐらいしろよ

つまらないのでWindows2000の話

[書き込みキャッシュを有効にする] 機能を有効にすると、データが失われる
http://support.microsoft.com/kb/281672/

書き込みキャッシュが有効な場合の遅いディスク パフォーマンス
http://support.microsoft.com/kb/332023/ja

「この修正プログラムは、実装に伴うリスクのレベルを理解および承諾し、
適切なハードウェアの電源保護によってこのリスクを軽減できるという確信がない限り、
実装しないでください。」

411 :login:Penguin:2007/01/20(土) 14:47:24 ID:UaLVa0QY
書き込み順序の問題はディスクのcacheが原因
http://slashdot.jp/linux/article.pl?sid=02/09/18/0623254&mode=nested

412 :login:Penguin:2007/01/20(土) 15:01:37 ID:UaLVa0QY
>>2.syncしないことで起こる別問題って何ですか?
ディスクに確実に書き込まれたことを保証しないといけない場合に困る。
syncの呼び出し後にネットワークで書き込み終了を通知したが、
実際に書き込まれる前に電源が落ちるといったケースが考えられる

>>3.自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか?
syncによって順序を保証する手法もある。
詳細はlinux/Documentation/block/barrier.txtを参照。
但し、処理によっては実用にならない程遅い可能性もある。

413 :409:2007/01/20(土) 15:15:27 ID:gfquQKqH ?2BP(0)
>>412
> >>3.自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか?
> syncによって順序を保証する手法もある。

実はここが聞きたかったわけで、そうすると
>>406
> 壊れるのは書き込みの順序が原因で、syncしないことは別問題
別問題とは言えないことを自ら返事されたわけです

414 :login:Penguin:2007/01/20(土) 15:54:53 ID:UaLVa0QY
>>413
確かにそうだけど…
softupdateなんかで依存の発生する場所全部にsyncを入れるのが
現実的?非現実的である証拠のデータが出せなくて申し訳ない
ですが…

415 :login:Penguin:2007/01/20(土) 16:16:11 ID:gfquQKqH ?2BP(0)
いえ、データ出すのは大変ですから
Windows2000でさえ両方の含みを残している
難しい判断なんでしょうね

416 :login:Penguin:2007/01/20(土) 17:08:10 ID:UaLVa0QY
ついでに、これも転載
http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028251.html

417 :login:Penguin:2007/01/20(土) 17:25:35 ID:snxMEiUl
>>416
そのスレを読んでいくと、ジャーナリングでもsoftupdate同様に
todays desktop drives can lie about writing data.
の影響を受けるっていう、このスレの流れと同様の話になっていっていますな。

418 :login:Penguin:2007/01/20(土) 23:02:52 ID:SqdA4hO3
ハードディスクが独自に高性能化を辿った結果、
書き込み順についてはどんなに直接sync命令しても確実に保証されるものではないってことかな?

今のhddじゃエレベーターシークアルゴリズムとかは意味がないか逆効果かもとどっかで見たことあるし。

419 :login:Penguin:2007/01/21(日) 02:52:54 ID:hY5qL1VD
>>418
SCSIとSerial ATA 2.5はFUAによってwrite cache有効時でも書きこみの完了を保証できる。
ので、ドライバがまともに実装されていればOK。
ATAはcache flushを保証する手段が用意されていないので何をやっても無理。

420 :login:Penguin:2007/01/21(日) 20:35:19 ID:4gtXWK3A
ZFSではwc対策はどうなっているの?



421 :login:Penguin:2007/01/21(日) 23:48:40 ID:AqF7ihH/
しかし、ジャーナリングファイルシステムって、電源断とかのトラブルでも
ファイルが壊れないようにするものじゃないのか。

実験室での使用なので、けっこう動作環境が良くないのは分かるけど
今日、ext3 また壊れてしまった。フォーマットからやりなおし。
土曜にバックアップとっていて良かった。
やっぱりXFSに移行するかな。

422 :login:Penguin:2007/01/21(日) 23:55:06 ID:xsvOt/km
ext3が何度も壊れ、
reiserfsの大パーティションのマウントの遅さが嫌になり、
XFSに行き着いて幸せになった俺

423 :login:Penguin:2007/01/22(月) 00:14:17 ID:ppnVbPRo
たしかに reiserfs はでかいパーティションのマウントに時間がかかるね


424 :login:Penguin:2007/01/22(月) 00:19:23 ID:RyHURUu7
ちょっと気になったのは、このスレの過去ログ読むとLinuxのVFSのせいで
XFSでもファイルシステムが壊れるって聞いたけど、どうなの?

425 :login:Penguin:2007/01/22(月) 00:34:54 ID:Mwx+Gzyg
XFSはファイルシステムが壊れるよ

ext3はファイルは守ってくれないが
ファイルシステムは守ってくれるので
まだ安心


426 :login:Penguin:2007/01/22(月) 00:56:30 ID:RyHURUu7
それじゃ、ダメじゃん。

427 : ◆IIiDC8JS7w :2007/01/22(月) 00:59:28 ID:v/DQ0Ap0
ZFS to the FUSE
まだα版だけど。。
つ ttp://developer.berlios.de/projects/zfs-fuse/


428 :login:Penguin:2007/01/22(月) 02:58:08 ID:4mh5V91p
まぁいろいろ悩む前にUPS買えってことで。
あとは日々のバックアップ。

429 :login:Penguin:2007/01/22(月) 04:59:17 ID:g7VFvdpY
FUSEじゃ読み書きできますよっていう程度で、本格的に使うのには
全然向かないな…

430 :login:Penguin:2007/01/22(月) 19:52:31 ID:aXULs4Jv
GFS使ってる人、手ageて。

431 :login:Penguin:2007/01/22(月) 19:54:33 ID:I6ul0rfb
デスクトップでJFS使い始めました。
前はReiserFSでした。
今のところ無問題。

432 :login:Penguin:2007/01/22(月) 21:44:43 ID:CllrhvyS
>>421
どんなFSでも、ジャーナルにしてもRAIDにしてもファイルが壊れない
(壊れ難い)という認識は止めたほうが安全。
復旧を早くする方法論と割切ったほうがいい。
大切なデータはきちんとバックアップすること。

433 :login:Penguin:2007/01/22(月) 21:46:12 ID:vkPy7i3I
>>431
毎日cvsでgcc取ってきてビルドしてみて。
漏れは3年前emacsでそれやってたらfs壊した(XFS)。

434 :login:Penguin:2007/01/22(月) 22:03:40 ID:+MxoKgNb
XFS ってそんなに弱い子なのか。

435 :login:Penguin:2007/01/22(月) 22:11:02 ID:gyatXghJ
gentooでほぼ毎日何かしらをコンパイルしたり、
時々動画をエンコしたり、
毎日えろまんがを読み漁っていますが、
XFSは元気です。

436 :login:Penguin:2007/01/22(月) 22:18:21 ID:6fw9D8r3
ファイルシステムを何にしてもHDDガリガリさせるのは
寿命を縮めるだけだから、できることならあまりやりたくないね。

437 :login:Penguin:2007/01/23(火) 00:06:35 ID:yhm1O3f9
>>436
それじゃlocateが動くLinuxは使えんがな。


438 :login:Penguin:2007/01/23(火) 10:58:00 ID:SMWMFAIy
locate は使えば便利なんだけど
知らない人とか使わない人にとっては負荷が無駄過ぎるな。
デフォルトで動くディストリも結構あるんじゃないの。

439 :login:Penguin:2007/01/23(火) 13:21:33 ID:Dh6zD8CC
HDDの代わりにi-RAMとかフラッシュディスクを使えば解決

440 :login:Penguin:2007/01/23(火) 13:28:42 ID:dy5DSgJl
ガリガリ使えばHDDよりフラッシュのほうが寿命短いんじゃないの?

441 :login:Penguin:2007/01/23(火) 14:18:58 ID:Qe3f9h84
そこでMRAMとか相変化RAMとかですよ!

442 :login:Penguin:2007/01/23(火) 14:32:40 ID:L6fiHwdO
HDD の寿命とか気にしてたらまともに使えんだろう

443 :login:Penguin:2007/01/23(火) 15:01:52 ID:5Whe9XEV
フラッシュの方が圧倒的に短いわなw


444 :login:Penguin:2007/01/23(火) 16:30:58 ID:JInqPF8n
ハイブリッドハードディスク楽しみだよねえ。っと。
http://www.itmedia.co.jp/news/articles/0504/26/news018.html

# スレ違い。

445 :俺用メモ:2007/01/23(火) 16:48:37 ID:JpiPeEcZ
<kernel-src>/Documentation/filesystems/ext4.txt
  NOTE: The "extents" mount flag is temporary. It will soon go away and
  extents will be enabled by the "-o extents" flag to mke2fs or tune2fs

http://www.die.net/doc/linux/man/man8/mkswap.8.html
  For kernels after 2.3.3 there is no such limitation

http://www.die.net/doc/linux/man/man8/mkfs.xfs.8.html
  the maximum size is just under 1 TiB.

446 :login:Penguin:2007/01/23(火) 17:00:50 ID:xbr0LMQ0
FUA 関係なくデータのロストが防げるなら
フラッシュは大歓迎なんだけど、
そういう目的じゃないようなので
Intel の Robson でいい気もする。

447 :login:Penguin:2007/01/23(火) 17:14:46 ID:0oMO9Ojw
>>446
> FUA 関係なくデータのロストが防げるなら

ハイブリッドディスクはデータロストしないんじゃねぇ?
ライトキャッシュが不揮発性というのは大きいと思うんだが

448 :login:Penguin:2007/01/23(火) 17:34:03 ID:0oMO9Ojw
もちろん、ソフト側が正しく制御する前提だけど

449 :login:Penguin:2007/01/23(火) 21:19:21 ID:SMWMFAIy
フラッシュメモリってライトキャッシュに使えるほど
書き込み耐久性あるの?

450 :login:Penguin:2007/01/23(火) 21:27:38 ID:xbr0LMQ0
フラッシュに入る前にも当然8MB程度の
RAMがキャッシュメモリとして確保されていると思われ。
なのでその部分はやはり揮発すると思う。

451 :login:Penguin:2007/01/23(火) 21:44:21 ID:L4TUXWzd
>>450
揮発するといってもトランザクションを実行するくらいの
コンデンサ容量は確保されてるでしょ・・・・

452 :login:Penguin:2007/01/23(火) 21:51:03 ID:0oMO9Ojw
>>450
ハイブリッドハードディスク
http://www.google.co.jp/search?hl=ja&q=%E3%83%8F%E3%82%A4%E3%83%96%E3%83%AA%E3%83%83%E3%83%89%E3%83%8F%E3%83%BC%E3%83%89%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

どこにも8MB程度のRAMのキャッシュメモリの話はないですが
自分で確認してください

453 :login:Penguin:2007/01/23(火) 22:17:31 ID:xbr0LMQ0
>>452
DRAM のキャッシュと不揮発のキャッシュを
併用することになっている。
http://pc.watch.impress.co.jp/docs/2006/0526/hot428_01.jpg

454 :login:Penguin:2007/01/23(火) 22:23:32 ID:0oMO9Ojw
>>453
http://japanese.engadget.com/2006/05/08/hybrid-hdd/
ハードディスクドライブのバッファを大容量NANDフラッシュメモリに置きかえたハイブリッドHDD

455 :login:Penguin:2007/01/23(火) 22:35:32 ID:8K+SLyEi
開発者の発表スライドにengadgetの記事で反論する珍行動

456 :login:Penguin:2007/01/23(火) 22:52:33 ID:xbr0LMQ0
>>454
そうは言うが、Samsungのホワイトペーパーでも

First, Hybrid HDD has flash memory playing a supplementary
role to DRAM in order to dramatically reduce the boot time
and improve system capacity.
http://www.samsung.com/Products/HardDiskDrive/whitepapers/WhitePaper_12.htm

とあるので、DRAMによるキャッシュも積んでいるんだと思う。
DRAM→NVRAMはいきなりの電源断でも書ききれるという意味で
データが失われないという仕組みは可能だと思うが、
DRAM無しというのは難しいんじゃないか?
そもそも上に出したWinHEC2006のスライドも元は
Samsungの描いた絵だし。

457 :login:Penguin:2007/01/23(火) 23:51:46 ID:0oMO9Ojw
>>456
>>453の図と>>456の図はほぼ同じなんだが、どちらの図にもI/O両方の矢印がある
この両方向でDRAMをスルーしてNVRAMにアクセスしている
ハイブリッドディスクはブート時に1-2KBのRAMにブートセクタをコピーするんだが、このDRAMキャッシュはその部分の事ではないのか?
>>456を翻訳しても、ズバリ、キャッシュに使っているというようには訳せないんだが

458 :457:2007/01/24(水) 00:17:56 ID:vzigmnXE
× NVRAM
○ NANDフラッシュメモリ

459 :login:Penguin:2007/01/24(水) 00:38:31 ID:uMM8sw+h
だから MRAM,FeRAM とかの高速不揮発メモリに
期待って話だったんじゃねーの?

460 :login:Penguin:2007/01/24(水) 01:39:30 ID:Wx+4qs1R
耐久年数と揮発/不揮発は関係あるの?

461 :login:Penguin:2007/01/24(水) 02:19:19 ID:OH8//z4U
耐久年数が多いと揮発しにくいので、一度書いたら
上書きがとても大変

462 :login:Penguin:2007/01/24(水) 08:32:43 ID:vzigmnXE
>>460
現行のフラッシュメモリは耐久年数は低いとされている
しかし、>459のMRAMは耐久年数のみならずスピード自体も揮発性メモリより高い
FeRAMもMRAMに準ずる

463 :login:Penguin:2007/01/24(水) 15:27:52 ID:fll6hQgJ
フラッシュメモリが高い耐久性を持ってなきゃいけない必要性はない。
ハミング符号なりで保護して不良部分を置き換える下のレイヤーを一
層設ければ耐久年数は無視できる問題ではないか?

464 :login:Penguin:2007/01/24(水) 16:04:57 ID:vzigmnXE
http://webleverage.jp/xen/wiki/index.php?howto#m6961cbc

Intel Macのマルチブートっておもしろいねえ
OSX用と全く同じ内容のMS-DOS用のパーティションテーブルを作ってるよ

465 :login:Penguin:2007/01/24(水) 16:17:28 ID:mEXlFMcS
>>463
そういうのも含めての耐久性じゃない?

466 :login:Penguin:2007/01/24(水) 16:22:03 ID:vzigmnXE
>>463
現状すでにやられてる話でしょ

467 :login:Penguin:2007/01/26(金) 03:11:35 ID:9ovjxSc8
現状でも、書き込み寿命の均一化はやってあるよ。
それでやっと今の寿命になってる。

個人的には、停電時にファイルを確実に守る方法は
UPS以外に有効な方法は無いと結論をだしてる。


468 :login:Penguin:2007/01/26(金) 15:45:58 ID:S6wJxTFd
確実な方法なんてないと知るところから全ては始まるんだがな。

# ようは何処まで守りたいか、という話

469 :login:Penguin:2007/01/26(金) 21:20:42 ID:LxxsiSqP
そういうこと
どこまで妥協できるかだね

470 :login:Penguin:2007/01/27(土) 02:04:17 ID:hzYyrGKz
俺は大切なデータは石に彫って埋めてる。

471 :login:Penguin:2007/01/27(土) 06:38:54 ID:E9E1wd6D
>>463
NAND型フラッシュメモリ
http://ja.wikipedia.org/wiki/NAND%E5%9E%8B%E3%83%95%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A5%E3%83%A1%E3%83%A2%E3%83%AA

一般的なデータ書き込みおよび消去後、
不良ブロックの検知処理を行い、
不良ブロックを管理するロジックが組み込まれている。
...
各ブロックの書き込み消去回数が平均化するようにする手法が広く用いられている。

472 :login:Penguin:2007/01/27(土) 09:08:22 ID:u9/4vZC9
>470
ちゃんと3か国語位は並べておけよ

473 :login:Penguin:2007/01/27(土) 09:57:51 ID:4NCB46QC
Hans Reiser、近況

ttp://opentechpress.jp/~sado/journal/432?from=rss

「Hansを陥れるための罠」を仕掛けたのは
ロシアのスパイ組織じゃなくてext4の中の人じゃないか?

474 :login:Penguin:2007/01/27(土) 10:21:57 ID:NEv34+KY
ロシアとはまた厄介な

475 :login:Penguin:2007/01/28(日) 21:50:55 ID:Znedwxfp
SDなんかだとうすっぺらいですが、あの中にそんなロジックが入ってい
るんですか? 知らんかっただけにちょっと驚き。

476 :絶対☆妹至上主義:2007/01/29(月) 02:05:06 ID:ncjfs3KH
>>471
NANDでも、何度でも書き込めるわけでは無いんだな

477 :login:Penguin:2007/01/29(月) 02:33:50 ID:dIKGkRrE
誰がうまいk(ry

478 :login:Penguin:2007/01/29(月) 13:41:07 ID:siKMYi/7
そのツッコミがなければボケの存在に気付かなかったよ。

479 :login:Penguin:2007/01/29(月) 22:12:15 ID:aMwlfPuf
>>475
それはデバイスドライバの仕事


480 :login:Penguin:2007/01/30(火) 22:33:33 ID:ysSJZIzG
ここならlusterやってる人いるかな
1.4系と1.6系があるんだが、どっち使ってる?


481 : ◆IIiDC8JS7w :2007/01/30(火) 22:40:38 ID:gRlPMLvw
今はLustre 1.6Beta7(2007/1/15付近にでたもの)

482 :login:Penguin:2007/01/30(火) 23:07:08 ID:ysSJZIzG
サンキュー>481
余ってるPCが4台ほどあるので、試しにluster組んでみるよ。


483 :login:Penguin:2007/02/01(木) 12:33:57 ID:AuhPSHSf
LinuxのVFSがダメだって何度もこのスレで見たけど、
具体的にどこがどのようにマズイの?

484 :login:Penguin:2007/02/01(木) 12:40:05 ID:z56kQWBE
syncを発行しているのに実際にディスクに書かない、と言うのが通説
(ちと古いか)。

485 :login:Penguin:2007/02/01(木) 16:31:34 ID:d0gGLI0t
>>484
最近のはFreeBSDもそうらしいね


486 :login:Penguin:2007/02/01(木) 17:04:59 ID:lF996rlo
(OSが)syncを発行して(書き込みOKもらって)いるのに実際に(HDDが)ディスクに書かない

487 :login:Penguin:2007/02/01(木) 17:07:38 ID:KD9t2gZH
1月版 ext3でデータが破損!? メモリ管理で不整合
http://www.atmarkit.co.jp/flinux/rensai/watch2007/watch01b.html
>Debian独自のパッチの影響

ZFS progress.
http://blogs.freebsdish.org/pjd/2007/01/28/zfs-progress/
>98% functionality is implemented and work.

488 :login:Penguin:2007/02/01(木) 17:23:14 ID:DApPY+KS
>>486
>>376でガイシュツ。あと、読み間違えてないか? 2.6.18ではDebianパッチの影響だけど、
2.6.19では標準のカーネルでも発生するぞ。

んで、ZFSはFUSEだから正直問題外。

489 :login:Penguin:2007/02/01(木) 17:32:32 ID:sGGvNr2g
誰も、2.6.19では起こらないといってないんじゃないかw

490 :login:Penguin:2007/02/01(木) 17:35:04 ID:RxKMsyN1
そもそも、ZFSなんてlinuxで使うやついないだろ


491 :login:Penguin:2007/02/01(木) 17:38:25 ID:lF996rlo
>using Linus' test-program the data corruption has been reported
>as far back as the 2.6.5 kernel. "It's not actually a new bug at all,"
http://kerneltrap.org/node/7517
実は2.6.5以降から問題は発生してたらすぃけど、どうなんでしょ。

それと486はSoftupdate vs Journalingの話かな、どっちかというと。

492 :login:Penguin:2007/02/01(木) 18:04:36 ID:z56kQWBE
>>491
問題はあったけど、2.6.19で表面化したと書いてあるだろう。
http://www.atmarkit.co.jp/flinux/rensai/watch2007/watch01a.html

493 :login:Penguin:2007/02/01(木) 18:15:01 ID:9sgJPste
>>484
ATAだとwrite cache無効に設定しないとあんまり意味ないし。
# 一回デフォルト無効にしたら遅すぎるっていう苦情だらけで
# デフォルト有効に
SCSIは問題無し。


494 :login:Penguin:2007/02/01(木) 18:16:32 ID:9sgJPste
>>484じゃなくて、>>485だった。

495 :login:Penguin:2007/02/01(木) 18:18:17 ID:DApPY+KS
うが、>>486じゃなくて>>487だ。

>>489
>>487の書き方は誤解を招くような代物だったので。

>>490
NTFSの場合はデュアルブートの際やUSB HDDつなげた際に読み込めるというメリットが
あるけど、ZFSにはそういうメリットないものねぇ。きちんとkernel空間で実装して
ext4、JFS、XFSなどと同様に標準fsとして使えるようになっているのなら話は全然別だけど。

ZFSに関してはFreeBSDやOS Xにどうportされるのか注目かなぁ。

>>491
とりあえず、大きなファイルをmmap()するようなアプリを使う際は2.6.19.2に
しておいたほうがいいというのは確かかな。>>487の記事では2.6.20rc3以降なら
fixとは書いてあるけど、2.6.19.2でもfixされたことは書いていないのがアレだ…

496 :login:Penguin:2007/02/01(木) 18:23:42 ID:z56kQWBE
>>493
ファイルシステムの下には ATAやSCSIのディスクだけじゃなくて、
SAS,バッテリバックアップされたRAID,iSCSI,AoEなどなど
いろいろあるんですが、そのへんはどうなんすかね?

497 :login:Penguin:2007/02/01(木) 18:31:16 ID:DApPY+KS
>>496
各種デバイスの仕様と、そのデバドラのつくりによるとしか言いようがない。

SCSIやSATAだとFUAが使えるからデータをディスクへ書き込んだ時点で
終了通知をホストへ返すことができるわけだけど、デバドラがきちんと
作られていないのなら、デバイスレベルでFUAをサポートしていても
無意味なわけで。

498 :login:Penguin:2007/02/01(木) 18:35:46 ID:MMx52a8R
ストレージクラスなら、キャッシュへの書込みが終了した時点で返す。
もっとも、それは電源がちょっと落ちたところでキャッシュの中身が消えることがないようになっているわけだが。


499 :login:Penguin:2007/02/01(木) 18:40:06 ID:eaIr3GB1
>484 が言っているのは >486 のより手前の
OS に責任があるレイヤでの問題

ただし、結局その説が正しいのかどうかはよくわからん

500 :login:Penguin:2007/02/01(木) 18:52:05 ID:z56kQWBE
>>499
だから、そんなレベルでOSが責任をとってもデータがダメになる
ケースは多数あるわけで、それなら始めからベストエフォートに
してページキャッシュをいろいろ最適化したほうがマシ、というのが
Linuxの設計方針だろ。Linuxカーネル解読室とか読めよ。

501 :login:Penguin:2007/02/01(木) 18:53:40 ID:8hEfCwF0
>>499
このスレでも何回か出ている話題だけど、>>384-419あたりの議論でだいたいの結論がついてないか?

502 :login:Penguin:2007/02/01(木) 20:50:11 ID:n6dF5ODI
>>500
それはおかしくないか?
ユーザーによってニーズは違うだろう
スピードへの最適化と信頼性への最適化の2つの選択肢を与えるべきじゃないのか?

503 :login:Penguin:2007/02/01(木) 21:04:29 ID:8kIqyObB
Linuxカーネル解読室ってオライリーのunderstanding the linux kernel 3rd edition より良いの?

504 :login:Penguin:2007/02/01(木) 22:04:54 ID:bacTwvVC
>>501
長すぎるからサマライズキボン。
キチガイは伝染する?

>>502
信頼性欲しければ違う実装使えってことだろ。
それか自分で作るか。作ってもLinuxにはマージしてもらえない気がするが。

>>503
後者の2版和訳を読んだ限り上っ面の説明しかできていない。
前者は読み込んでないから知らぬ。


505 :login:Penguin:2007/02/02(金) 02:15:32 ID:LHpcI4XW
>500
そんなヌケサク説明を本気で信じてるの?

解決策にもなんにもなってないし...

506 :login:Penguin:2007/02/02(金) 21:15:48 ID:FrGCgZny
結局、まっとうな批判に対して「キチガイ」と罵ることしかできない
ということでFAか?


507 :login:Penguin:2007/02/02(金) 21:24:00 ID:zNdISUUI
はいはい

508 :login:Penguin:2007/02/02(金) 21:28:42 ID:T7lvryZy
いや、大したことのないレスにキチガイって返す方がおかしいよ

509 :login:Penguin:2007/02/03(土) 03:37:04 ID:kg/qeKbc
>>491
その情報が正しいとなると、RHEL4.5で修正入るのかな?

510 :login:Penguin:2007/02/03(土) 14:58:47 ID:5bzUz2co
とりあえず、504は放置しとけ

511 :login:Penguin:2007/02/04(日) 12:40:11 ID:SIrUcCus
XFSとext3とReiserFSだとどれが安全?

512 :login:Penguin:2007/02/04(日) 12:43:34 ID:I1zy8FgT
どれも危険極まりない。
お前が使えば。


513 :login:Penguin:2007/02/04(日) 16:27:09 ID:VendWddW
>>511
今からならReiserFSがいい。
状況は今がドン底。逆にこれ以上悪くなる心配がない。
後は這い上がるのみ。

514 :login:Penguin:2007/02/04(日) 17:21:58 ID:J2syga+J
>>511
つかちょっと上のレスも見らんないのお前は?

JFSだけはガチってのがこのスレの総意だろ。

515 :login:Penguin:2007/02/04(日) 17:33:06 ID:OnmEjYbp
ガチ、か…

516 :login:Penguin:2007/02/04(日) 18:34:37 ID:e+PaBkqY
スルーされ具合についてはガチだな

517 :login:Penguin:2007/02/04(日) 18:38:09 ID:KaQxELcg
今からならReiser4だろ

518 :login:Penguin:2007/02/04(日) 18:41:31 ID:OUXrG2xd
俺はせっせと Solaris に移行中

519 :login:Penguin:2007/02/04(日) 22:08:15 ID:SIrUcCus
JFSのトラブルの報告が無いのは誰も使っていないからだろ?

520 :login:Penguin:2007/02/04(日) 22:10:05 ID:/f4Jfrib
Yes, SIr!

521 :login:Penguin:2007/02/04(日) 22:12:54 ID:6B5J03Tx
使ってますが何か

522 :login:Penguin:2007/02/04(日) 23:07:54 ID:BkRpNHOD
>>521
お前だって、最悪飛んでもいいパーテーションでしか使ってないだろ。

523 :login:Penguin:2007/02/04(日) 23:15:37 ID:wTKNJ/kp
>>518
Solarisって使いやすさはどうなの?
パッケージ管理が簡単なのかどうかと、パッケージ数が豊富なのかどうかが気になる。
昔はGCC入れて、各種アプリを自前コンパイルしないといけない時代があったよね。

524 :login:Penguin:2007/02/04(日) 23:24:50 ID:I1zy8FgT
今も基本的にはそうだが。
Sunfreewareのビルドが気に入らなければ、自分で作るしかないから。
パッケージ管理そのものについても、RPMやdebほど洗練はされていない。
パッチとか当てると普通に設定ファイルを上書きしたりするから、注意がいる。


525 :login:Penguin:2007/02/04(日) 23:34:10 ID:9s1+/enK
JFS はハードディスクが壊れただけでファイルシステムがぐちゃぐちゃになったので糞。
あと、NLS でちゃんと変換出来ないファイル名のファイルを作るとロストするときがあったので糞(相当昔の話だが)。

526 :login:Penguin:2007/02/04(日) 23:45:28 ID:ScyYaqVx
> JFS はハードディスクが壊れただけでファイルシステムがぐちゃぐちゃになったので糞。

527 :login:Penguin:2007/02/04(日) 23:53:20 ID:l/38o1m3
ちゃんと書かないとつたわらないだろうな

528 :login:Penguin:2007/02/05(月) 00:10:05 ID:xJuCgkva
HDD が壊れても大丈夫な FS 欲しいなぁ

529 :login:Penguin:2007/02/05(月) 00:11:54 ID:yquMgini
>>528
ひょっとしてそれはギャグで言ってるいるのか?


530 :login:Penguin:2007/02/05(月) 00:18:06 ID:rnFpdWND
ネットワークファイルシステムならHDDに書かないから安心。

531 :login:Penguin:2007/02/05(月) 00:21:47 ID:BjEiAhlg
サーバ側のローカルファイルシステムが(略

532 :login:Penguin:2007/02/05(月) 00:51:26 ID:TwCWVt0g
ネットワーク上に不良パケットとして放流するファイルシステム。
寿命が尽きる前に再放流。
常にネットワーク上をさまようデータたち。

533 :login:Penguin:2007/02/05(月) 00:57:12 ID:3z2RfYJO
Winnyファイルシステムかよw


534 :login:Penguin:2007/02/05(月) 01:06:37 ID:ikYVMwPI
>533
セキュアさが技術的に担保されるなら大アリ。
というか、似たものは既にある。


535 :login:Penguin:2007/02/05(月) 02:16:43 ID:3k+6xyTA
XFS使い始めて、もう1年になるがこの間、FSごと壊れたのは
まだ3回しかないが、これは運が良かったのか?

536 :login:Penguin:2007/02/05(月) 02:32:05 ID:B8r6Q64G
3回も壊れてるとかチョーウケル。

537 :login:Penguin:2007/02/05(月) 02:34:35 ID:1UIejfif
HDDが壊れたんだよな?

538 :login:Penguin:2007/02/05(月) 04:49:19 ID:3k+6xyTA
>>535 のHDDは物理的には全然平気だった。

そのHDD、別のPCに入れてWindowsXPで
使っているけど、普通に動いている。

539 :login:Penguin:2007/02/05(月) 07:08:06 ID:FEECW1nx
チキンは俺は ext3

540 :login:Penguin:2007/02/05(月) 11:36:52 ID:dxgxznv4
一度 RAIDコントローラが発狂して全滅したことはあったけど、
8年間使っててext2|3,reiser3,xfs,jfsいずれも問題ないな。
もちろん適材適所だよ。

541 :login:Penguin:2007/02/05(月) 16:16:34 ID:1UIejfif
>>538
情報thx
3度もというと結構多い感じするけど、どういう状況でそうなったの?
電源プチとかブレーカー落ちたとかそういうH/Wまわりしか思い浮かばなかったんだけど
IRIXでXFS使ってたときはFS壊れたことっていうのが無かったので

542 :login:Penguin:2007/02/05(月) 17:09:15 ID:kXNVJxPh
IRIXも最初のころはFSに限らずしょぼいしょぼいといわれていたけどね!

543 :login:Penguin:2007/02/05(月) 22:41:56 ID:xJuCgkva
最後までショボイまま終わったと?

544 :login:Penguin:2007/02/06(火) 23:35:16 ID:wGCOby4y
Excelが同期書き込みを使っているように感じているのは俺だけなのだろうか?

545 :login:Penguin:2007/02/08(木) 21:38:43 ID:yfGJF1IC
Excelってそれどんなfs?

546 :login:Penguin:2007/02/08(木) 21:49:46 ID:xdYwexjj
NTFS

547 :544:2007/02/08(木) 22:00:34 ID:xdYwexjj
1.セーブアイコンをクリック
2.ハードディスクがガリガリいいはじめる
3.マウスポインタは砂時計表示に
4.ステータスバーの進捗状況が作業中を表示
5.ステータスバーの進捗状況が作業終了を表示
6.ハードディスクがガリガリ音が止まる
7.マウスポインタが通常に戻り、Excelに制御が戻る

いつもこのような状況なのでそう思っただけ
ちなみにハードディスクはパラレルATA

548 :login:Penguin:2007/02/08(木) 22:09:56 ID:9ICUpqjJ
>>547
最近はLinuxでもExcelが動くようになったんですね。
是非、方法を教示していただきたいのですが。

549 :login:Penguin:2007/02/08(木) 22:14:14 ID:yfGJF1IC
>>547
(・∀・)・・・・・・・・こ、これは・・・・

                 ゴメンいい釣られ方思いつかなかった

550 :login:Penguin:2007/02/08(木) 22:22:51 ID:xdYwexjj
>>548
>>549
Excelの例をだしたのは悪かった

言いたいことは一つで、パラレルATAが同期書き込み不可なのが
正しい根拠があるのか疑問をもっただけ
FUAがないだけでは根拠にならないから

551 :login:Penguin:2007/02/08(木) 22:24:56 ID:xI5jKKjE
有るし

552 :login:Penguin:2007/02/08(木) 22:26:01 ID:xdYwexjj
>>551
ソース希望

553 :login:Penguin:2007/02/08(木) 22:38:19 ID:xdYwexjj
ATA
http://community.osdev.info/index.php?ATA

ちなみにここでATAのコマンドを調べると、

0xe7に
0xe7 No-Data FLUSH CACHE

これはPIO制御なのでUDMA時は発行できないのかもしれないが
0xe8 PIO-Write WRITE BUFFER

こういうのもあるんだが

554 :login:Penguin:2007/02/09(金) 00:41:33 ID:Zb41PA+h
>>548
wine

555 :login:Penguin:2007/02/10(土) 23:48:20 ID:DJ1EsE63
今日、USBメモリを挿入した瞬間OSがフリーズした。
リセットボタン押して再起動したら、ファイルが lost+found に
大量に送り込まれた... orz
ext3 お前もか...

FC6やめた方がいいかな?

556 :login:Penguin:2007/02/10(土) 23:52:49 ID:rfqyKqr7
pugya-

557 :login:Penguin:2007/02/11(日) 00:34:30 ID:LZDtKzf8
>>553 ディレクトリ操作中に電源を落とした場合の典型的な症状だ
と思うけど。まさかそういうのも含めて「ファイルシステムが壊れた」
とか言ってるの?

558 :login:Penguin:2007/02/11(日) 00:47:04 ID:ukTcRXps
>USBメモリを挿入した瞬間OSがフリーズした。
が一番Linuxのダメさを表わしてるわな。


559 :login:Penguin:2007/02/11(日) 00:52:07 ID:CJAQk2DO
>>558
俺もその光景を目撃した経験があるな...
エンジニアが若いSEに必死で弁解してたよ

560 :login:Penguin:2007/02/11(日) 01:01:56 ID:3+IsEM3X
俺iPodをWindowsマシンに接続した瞬間にブルースクリーンになったことある。
同じマシンに入ってるLinuxではちゃんとiPod使えたのに。
で、そういうトラブルのときWindowsでは対処法を探すのが難しいんだよな。

561 :login:Penguin:2007/02/11(日) 01:02:23 ID:/aD5Y840
脳内で fs 障害が発生しているようで、ご愁傷様です。

562 :login:Penguin:2007/02/11(日) 01:14:56 ID:ukTcRXps
まあ、USBはChipが悪いのが原因てことも多いからな。


563 :login:Penguin:2007/02/11(日) 11:24:35 ID:t4TvBlHe
いきなりリセットかけたときの、ファイル or FS へのダメージに
関して言えば、最近はLinuxよりもWindowsの方が安全なように
思えるようになってきた。

564 :login:Penguin:2007/02/11(日) 11:42:26 ID:P7PjeCmr
>>563
今ごろ気付いたのかよ

565 :login:Penguin:2007/02/11(日) 12:56:32 ID:iSwVn+BM
>563-564
この間LinuxとWindowsをVMwareのゲストで動かしてる最中に停電でホストが落ちちゃって、
再起動後どっちのゲストも起動しなくなっちゃったんよ。

Linux(ext3)の方は仕方ないからシングルユーザモードで起動してfsckかけたんだけど、
Windows(NTFS)の場合は一体どうしたらよいか分からなくて、現在進行形で途方に暮れてる。
何度スキャンディスク掛けても復活しないし。

566 :login:Penguin:2007/02/11(日) 13:28:42 ID:OboOTrcF
pugera

567 :login:Penguin:2007/02/11(日) 13:53:58 ID:itbL0uDG
>>562
チップじゃなくて外付けの回路かもな。
ろくにテストも出来ない検査が駄目なのか、
検査基準を甘々にしなけりゃならない程、
ハード屋がだらしないのか知らんけど。

568 :login:Penguin:2007/02/11(日) 18:05:38 ID:4xgL+aKM
>>565
たまたまだろ
Linuxだって死ぬときゃ復活もクソも無い

569 :login:Penguin:2007/02/11(日) 23:11:39 ID:t4TvBlHe
うちの会社では最近では、逆に Windows鯖も置くようになってきた。
昔のようなLinuxに対する神話というか盲信がなくなってきたからね。

570 :login:Penguin:2007/02/11(日) 23:23:04 ID:4cTo2V09
>Linuxに対する神話

ナニソレ?

571 :login:Penguin:2007/02/11(日) 23:53:13 ID:t4TvBlHe
Linuxは安定している。Linuxは安全である。Linuxは高性能である。
Windowsはその逆、っていう話のことを言った。

572 :login:Penguin:2007/02/12(月) 00:02:21 ID:CJAQk2DO
>>571
確かにそういう神話はあった
Linux関係の雑誌は特にひどかった
とりあえず褒めておけば売れるだろうという姿勢がみえみえだった

573 :login:Penguin:2007/02/12(月) 00:08:28 ID:ehOYrnXS
Xを使うと、Linuxは非常に重かったが、Windows95はPentium160Mhz,32MBでサクサク動いた(不安定だが)
このあたりの事は一切ふれられず、Linuxは軽いと言われてた
かくいう漏れも信じていたが

574 :login:Penguin:2007/02/12(月) 00:18:36 ID:c1CrXUSo
そんなに性能あれば X 使ってもサクサク動くね。

575 :login:Penguin:2007/02/12(月) 00:22:43 ID:vlEBE2dx
なぜかSolaris鯖復活。x86版だけど。

576 :login:Penguin:2007/02/12(月) 00:37:24 ID:ehOYrnXS
>>574
実際使った事あるのか?

32MBのメモリじゃXはスワップしまくって実用に耐えなかった
サービス止めまくってウィンドウマネージャにAfterStepなどを使っても無理
topでメモリ使用量見るとXだけで100MBぐらい使ってた
Xを使わなければ快適だったよ

577 :login:Penguin:2007/02/12(月) 00:47:48 ID:pKQ9EzWP
>>576
AfterStepじゃだめだ、tvtwm(twmよりも何故か軽い) とかにしないと...

578 :login:Penguin:2007/02/12(月) 00:50:45 ID:HIG9qOky
はて?
うちのdebianくんは、KDE3.2をスタートした時点で、トータル100MBも使ってないけど。
しかも、SendmailやらApacheやらいろんなサーバが起動した状態で。


579 :login:Penguin:2007/02/12(月) 00:53:19 ID:ehOYrnXS
>>577
tvtwmは使わなかったがtwmは使ってみたよ
結果は全くだめ
問題はX自体のメモリ消費量なんだよ

> AfterStepじゃだめだ、tvtwm(twmよりも何故か軽い) とかにしないと...
こういう事言ってる事自体が重い証明だろ

580 :login:Penguin:2007/02/12(月) 00:56:02 ID:tKkO1evC
フォント読み込みすぎだったんじゃね。
あとtwmよりfvwmのほうが軽かったような。

581 :login:Penguin:2007/02/12(月) 00:59:08 ID:ehOYrnXS
>>578
> うちのdebianくんは、KDE3.2をスタートした時点で、トータル100MBも使ってないけど。
それは異常だよ
漏れは256MBのVine機を持ってるが、Xを使ってしばらくたつと必ずスワップする
俺もLinuxは好きだが、神話はうんざりだ

582 :login:Penguin:2007/02/12(月) 00:59:32 ID:gH4+PeS3
もうコンソールでいいよw

583 :login:Penguin:2007/02/12(月) 01:02:56 ID:pKQ9EzWP
でもFSが壊れるのは神話じゃなくて事実だよね。

VFSが安定しない限り、この状況は続く...

584 :login:Penguin:2007/02/12(月) 02:21:48 ID:ue41F/Co
昔 166MHz 32MB で X と windowmaker と emacs と kterm 同時に使ってたけど
普通に使えてたよ。XFree 3.x 時代ね。
さすがにネスケとか立ちあげる時は emacs 落とす必要があったけど。
ただ、その後 update していくなかで X はどんどん重くなっていったので、
最新の X 入れたりしたらさすがに32MBじゃ足りないんじゃないかな。

585 :login:Penguin:2007/02/12(月) 02:36:22 ID:CD7jXCIx
はて?
うちのUbuntuくんは、Gnome2.16.1をスタートした時点で、600MBも使ってないけど。

586 :login:Penguin:2007/02/12(月) 02:47:55 ID:xmU+xA4+
793876 tty1 SL Feb11 37:31 Xgl
88540 ? Ssl Feb11 4:19 java v2c
76460 ? Sl 02:35 0:21 fx2

食いすぎだよな。
Xgl単独で800Mってもうあふぉかと。
beryl再起動直後でも458780。

587 :login:Penguin:2007/02/12(月) 02:50:36 ID:ue41F/Co
>>581
スリープ中のバックグラウンドプロセスじゃないの?

588 :login:Penguin:2007/02/12(月) 02:52:51 ID:PeW+mj3q
サーバでGUI常時動かす時点でどうかしてる。
ところがwindowsはGUIにOSがくっついていてGUIを止めれない。

スレ本来のFSに注目すると、
windowsのFSが逝きにくいのは事実。
だけれども、書き込み時のバッファフラッシュが強烈に重い。

linuxはVFSの段階でアクセスを最適化しようとするので重くなりにくいが、
その反面電源落ちクラッシュしやすい。


589 :login:Penguin:2007/02/12(月) 02:55:18 ID:s17apHnG
昔のは本当に軽かったんだよ
最近のは Window Manager に何を使っても重い
長年 fvwm だったが beryl にしてエフェクト使いまくっても
その差が体感できなかった

590 :login:Penguin:2007/02/12(月) 03:02:39 ID:ehOYrnXS
>>584
実用に耐えなかったというのはあくまで自分の主観で、遅くても動いていたことは間違いない
これを使えると思うかどうかは、各自の主観によると思う
しかし、後でWindows95とデュアルブートにした際にWindows95の軽さに驚いた
実機で16MBでも快適動作するのを確認している

591 :login:Penguin:2007/02/12(月) 10:54:39 ID:m2mmtgAx
ここって何のスレ?

592 :login:Penguin:2007/02/12(月) 11:10:27 ID:dthoHvZf
Windows9x系はさすがに話にならんだろ。
しかしNT系になって実装もそうだけど、設計でもUNIXは抜いたと思う。
MSは実装だけでなくアーキテクチャ設計能力も高い。

特にサードパーティによる新デバイス対応やOS拡張ができるようにする
モジュール構造は実世界で揉まれてるだけあって先を行ってるし、
どのOSでも一番問題を起こすドライバ系の安定度を高めるための
検証フレームワーク整備や教育といった面でも抜かりない。FS面でもNTFSは
安定してること以上にマルチストリームとかトランザクション対応とか
新機軸を着実に導入してるし、ユーザランド側でもPowerShellとかWSHと
いった洗練された仕組みがここ10年で着実に入ってる。

元ネタが○×でコピっただけとか厨が煩いことがあるけど、設計・実装は
NT登場以来驚異的に高くなってるし、そもそも他の会社が対抗できてない。
上から下まで、技術・非技術面までひっくるめて整備してくるMSのこの底力が
一番すごい。

正面からNTFSに対抗できる存在としてReiser4に超期待してたんだけど・・・
まあReiser4が駄目でもZFSとかFUSEとかGFSとか面白いものはたくさん
あるけど、MSは侮れんよ。

593 :login:Penguin:2007/02/12(月) 13:19:52 ID:pKQ9EzWP
Reiser4、漏れも期待していたけど、あの様子では主流にはなれないだろうな。
いろいろな意味で...

結局、Linuxカーネル開発者な連中は、Reiser4を闇に葬るんじゃないだろうか?

594 :login:Penguin:2007/02/12(月) 13:56:34 ID:1qjVTFhI
> ここって何のスレ?

top の出力眺める誰でも出来る仕事の人が、日頃妄想していることを書く場所。

595 :login:Penguin:2007/02/12(月) 15:52:05 ID:DZj/9zPx
>>593
確かにいい口実にはなったよな。

596 :login:Penguin:2007/02/12(月) 16:33:24 ID:ehOYrnXS
カーネル開発者たちはReiser4が独自IOルーチンを実装していることを非難してるが、
ReiserFS側が一方的に悪いとも思えないな

597 :login:Penguin:2007/02/12(月) 16:36:32 ID:V8V5NCDB
>Reiser4が独自IOルーチンを実装
XFSは良くてReiser4がダメな理由ってなんだろ?

598 :login:Penguin:2007/02/12(月) 16:39:03 ID:DZj/9zPx
>>597
開発者の性格

599 :login:Penguin:2007/02/12(月) 16:39:15 ID:ehOYrnXS
Hans Reiserが嫌われてるからだろ

600 :login:Penguin:2007/02/12(月) 16:52:04 ID:9DGMw6Vy
ユダヤの陰謀

601 :login:Penguin:2007/02/12(月) 18:18:43 ID:fU0muqJg
lustre1.6beta7を入れてみたのだが、OSTをmkfs.lustreしたあとmountするところで
カーネルパニックしてしまう。
beta7ちゃんと使えてる人いたら教えて下さい。

602 :login:Penguin:2007/02/13(火) 04:46:11 ID:IyOcykyK
しかし、Reiser4の開発者の性格がいくら悪くても、
漏れ的には、今まで一番トラブルの無かったファイルシステムが
ReiserFSなんだよな。
というぐらい今まで、LINUXのFSには酷い目にあっている。

603 :login:Penguin:2007/02/13(火) 07:26:14 ID:keBYA0IK
>>596
Linuxの悪口として、I/Oが腐っているというのはよく言われることだからね。
独自実装したくなるぐらいに腐っているというのを、Linux系の有名開発者自らが
実践しちゃったんだから、kernel開発者としては捨て置けなかったんだろうけど。

Hansを非難するよか、まともなI/Oを実装することに力を注いでほしかったね。

604 :login:Penguin:2007/02/13(火) 08:40:14 ID:WemlgHvo
具体的にI/Oのどの機能がよくないんだ?

605 :login:Penguin:2007/02/13(火) 08:56:45 ID:fVgYhrXm
reiser たんは、あれだよね
他のカーネル開発者への礼節が欠いてるんだよな
それで嫌われてる、確か

606 :login:Penguin:2007/02/13(火) 08:58:49 ID:0u58eKNV
http://bulk.fefe.de/

filesystem: Unix filesystem scalability benchmarks (Linux Kongress 2006)
は、単純なベンチとはいえFSでこんなに違うんだなーってのが分かるな。
reiser4が速すぎで、嫉妬心から嫌われる理由になるのも分かる(違

信頼性を定量的に測定できればいいのにね。

607 :login:Penguin:2007/02/13(火) 09:03:38 ID:/i03HF+s
詳しいことはよくわからないんだが、
ライザーのコードにはassertマクロがたくさん入ってたので、あるカーネル開発者が「読みにくいから削除してくれ」と注文をつけたらしい。
ライザーが「そんなこという奴は素人だ」と言い返したので、こじれたのだとか。
逸話が本当なら、カーネル開発者が素人なのは間違いないが、ライザーももっといいかたがあっただろうにな。

608 :login:Penguin:2007/02/13(火) 09:10:45 ID:/i03HF+s
Reiser4はファイルシステムのサイズ変更に対応してないんだよな。
先日、変更が必要になってそのことに気付いた。
データの引っ越しがめんどくさかったのでいまはバージョン3を使ってる。

ところでevms使いこなしてるひといる?
なかなか思うようにならなくて苦労してるのだが、、

609 :login:Penguin:2007/02/13(火) 09:11:22 ID:M3BPWPHj
UNIXのファイルシステムは、みんなトロイのばっかだからな
ディスクアクセスがいま一番ボトルネックで
データベースとかのベンチだと、明らかな差が出てくる
データベースはできるだけオンメモリで動作させるのが鉄則で
できるだけディスクアクセス少なくするんだけど
それでも、ディスクアクセスは避けられない
LAMPがはやるのもわかる気がする

610 :login:Penguin:2007/02/13(火) 09:34:49 ID:58Yqf8Hg
最後の文との関連が意味不明

611 :login:Penguin:2007/02/13(火) 09:36:06 ID:fVgYhrXm
Gentooの創設者もいってたな
あんなとろいファイルシステム使ってたら、日がくれちゃうよってw
Gentooはコンパイルして、ディスクアクセス頻繁に行うから

612 :login:Penguin:2007/02/13(火) 09:39:39 ID:M3BPWPHj
GentooはReiserFS推奨なんだっけ?


613 :login:Penguin:2007/02/13(火) 09:46:38 ID:x7MyuWlT
ttp://www-06.ibm.com/jp/developerworks/linux/011109/j_l-fs2.html
古いけど、ext2で2分かかっていた処理がReiserFSでは15秒で終わるって言ってる。

614 :login:Penguin:2007/02/13(火) 09:46:54 ID:Bu7+VNy+
パフォーマンスと引き換えにファイルロストというすばらしい特徴を備えているけどなorz


615 :login:Penguin:2007/02/13(火) 09:52:40 ID:s1yugE0P
2.6.10くらいからしか使ってないが、ファイルロストなんてないよ。
FUDイクナイ

616 :login:Penguin:2007/02/13(火) 09:56:29 ID:zEMqaX8A
>>615
その昔にはあったんだよ。俺も引っかかったが。
ファイルシステム全体が破損して復旧不可能になるという素晴らしいバグが。

Hans Reiserの件は抜きにしてもその時の記憶があって精神的に
reiserfsを使いたくないというユーザが数多くいたりする。

617 :login:Penguin:2007/02/13(火) 10:09:51 ID:fVgYhrXm
IBMはいつのまにこんな文章のせてたんだ
俺もReiser使ってみよ

618 :login:Penguin:2007/02/13(火) 11:00:48 ID:d9NUXbGG
kernel 2.2時代の話を蒸し返されてもねぇ

619 :login:Penguin:2007/02/13(火) 12:30:28 ID:+OHugGIQ
2.4だろ

620 :login:Penguin:2007/02/13(火) 20:06:01 ID:0ByefPAX
>>616
どこで聞き齧ってきたのか知らんが、過去に騒がれたのはバグじゃなくて互換性。
バージョン間の互換性が低くて、古いカーネルでマウントして壊す奴が大漁発生。

621 :login:Penguin:2007/02/13(火) 20:24:40 ID:zEMqaX8A
>>620
それは十二分に致命的なバグだろうに。
あとscpするとファイルシステムごとクラッシュする問題もあった。

622 :login:Penguin:2007/02/13(火) 22:24:46 ID:WemlgHvo
>>609
データベースでファイルシステムがボトルネックになる時は
raw モードを使うよね。製品ごとに呼び名は違うみたいだけど。

623 :login:Penguin:2007/02/13(火) 22:28:53 ID:mh7vvqPu
ぼくも raw モードでセックルしていまつ。

624 :login:Penguin:2007/02/13(火) 22:30:04 ID:WemlgHvo
>>607
アサーションはきちんと入れた方がいいよな。
プログラマーの意図を的確に表したアサーションはコメントに勝ることも多いし。
本当に必要なアサーションをさして、あるいは特定のアサーションを指さずに
全体的にアサーションが多めというだけでアサーション減らせって
指摘したならそいつの方が間違いだと思う。
実際にコードも読まずにこれ以上なんとも言えないけど。

625 :login:Penguin:2007/02/13(火) 22:48:26 ID:mh7vvqPu
> 実際にコードも読まずにこれ以上なんとも言えないけど。

あることないこと書いて炎上するほうが楽しくね?

626 :login:Penguin:2007/02/13(火) 22:51:47 ID:aW6CdUS7
ようするに全てはユダヤの陰謀ってことで

627 :login:Penguin:2007/02/13(火) 23:33:59 ID:IyOcykyK
Reiserの逮捕事件って、実はkernel開発者の陰謀だったりして。

628 :login:Penguin:2007/02/14(水) 00:01:31 ID:8Y630KZm
NovellがMicrosoftへの忠誠の証として人身御供にされた...とか。
もしかしてSCOのダールたんが暗躍してたり。

629 : ◆IIiDC8JS7w :2007/02/14(水) 00:59:07 ID:WbKlTUui
>>601

mds/mgsはちゃんとmountできてますか?
lustrekernelかなぁ?e2fsprogsは更新した?

例;(必要ならば--reformat付きでmkfs、fsnameをtestfsとした場合)
mkfs.lustre --fsname=testfs --mdt --mgs /dev/hda6
mount -t lustre /dev/hda6 /mnt/mdt
確認 cat /proc/fs/lustre/devices

○mgsノードを指定してmkfs
mkfs.lustre --fsname=testfs --ost --mgsnode=comp001@tcp0 /dev/hda7
mount -t lustre /dev/hda7 /mnt/test/ost0

○mgsノードでostが認識されているかどうかチェック
確認 cat /proc/fs/lustre/devices

lustre 1.6Beta7は設定も楽になったし、結構安定してきたと思うんだけどなぁ
動的追加もostのmountでできるし。。
lustreをNFSmountして使用する以外なら。。

630 :login:Penguin:2007/02/15(木) 06:48:33 ID:tOeafQO2
>>470
ヨーロッパの寺院とかに行ってみろ
墓標の上をみんな歩いてて、石の表面に彫られた文字も
磨り減って読めなくなってるから

631 :login:Penguin:2007/02/15(木) 17:16:25 ID:WROae+uz
ベトナムで鳴らした俺達ファイルシステム部隊は、濡れ衣を着せられ当局に逮捕されたが、
刑務所を脱出し、地下にもぐった。
しかし、地下でくすぶっているような俺達じゃあない。
筋さえ通ればフォーマット次第でなんでもやってのける命知らず、不可能を可能にし巨大なファイルを
貯蔵する、俺達、ファイルシステム野郎Aチーム!

俺は、リーダーntfs。通称MS謹製。
大容量と耐障害性の名人。
俺のような高信頼性FSでなければ百戦錬磨のつわものどものリーダーは務まらん。

俺はext3。通称Linuxの落とし子。
自慢のジャーナリングに、UPSはみんなイチコロさ。
ハッタリかまして、大容量ファイルから大容量ボリュームまで、何でもそろえてみせるぜ。

私は、HFSX、通称マカー。
チームの紅一点。
相互互換は、美貌とAppleTalkで、お手のもの!

よおお待ちどう。俺様こそRaiserFS。通称クレイジーFS。
アクセス速度は天下一品!
飛ぶ?壊れる?だから何。

FAT32。通称DOSあがり。
ロングファイルネームの天才だ。リソースの少ないPDAでもブン殴ってみせらぁ。
でもOver2GBだけはかんべんな。

俺達は、道理の通らぬ世の中にあえて挑戦する。
頼りになる神出鬼没の、ファイルシステム野郎 Aチーム!
助けを借りたいときは、いつでも言ってくれ。

632 :login:Penguin:2007/02/15(木) 17:55:02 ID:xfBVvXN9
元ネタ古いなぁ・・・

633 :login:Penguin:2007/02/15(木) 18:47:57 ID:OUJa5vmP
別にそれぞれキラリと光るキャラ設定があるわけじゃないし

634 :login:Penguin:2007/02/15(木) 18:50:48 ID:WROae+uz
だよね。
ジェネレータみつけて勢いにまかせて作ってやり場に困って投下しました。
ごめん。

635 :login:Penguin:2007/02/15(木) 23:32:42 ID:EOMAzg7P
まあいいんでないか。

636 :login:Penguin:2007/02/17(土) 22:11:48 ID:0e5NoIPn
あのさ、あのさ、今さらながら reiser さんの良からぬ話を知ったんだけどさ、
今、会社で管理してる ReiserFS なサーバーは、やっぱり次に再インストールでもする際に
ファイルシステムを変えたほうがいいと思う?

637 :login:Penguin:2007/02/17(土) 22:29:13 ID:Oo4vzhEt
まったく思わない。

638 :login:Penguin:2007/02/17(土) 22:32:52 ID:YLjvBpYU
ReiserFS 3.xは既に開発が終わり、カーネルにマージされてるから当面は問題はないでしょ
Reiser4はカーネルにマージされていないのでこれも問題ない

漏れは当面は様子を見る

639 :login:Penguin:2007/02/17(土) 23:07:39 ID:CxH4DkuK
>ReiserFS 3.xは既に開発が終わり、
メンテされなくなったら、追い出されるよ。


640 :login:Penguin:2007/02/17(土) 23:16:21 ID:YLjvBpYU
いずれな

641 :login:Penguin:2007/02/17(土) 23:16:24 ID:KFSDQiDM
ext2はどうなんだ?

642 :login:Penguin:2007/02/17(土) 23:20:17 ID:YLjvBpYU
追い出されるのが、例えば数年後なら俺的には何の問題もない
開発がストップしていれば性能面の魅力も消えているだろうから

しかし、状況は流動的

643 :login:Penguin:2007/02/18(日) 01:49:30 ID:lw5RYTmu
ext2は fsckが死ぬ程遅いからなぁ。

644 :login:Penguin:2007/02/18(日) 08:53:56 ID:RRBoRWUE
Linux終ったな

645 :login:Penguin:2007/02/18(日) 16:16:45 ID:+2MIv5gi
ext2でいい用途なら、ext3でいいのでは? >> 643



646 :login:Penguin:2007/02/18(日) 16:24:16 ID:x2PO8wq2
>>645
> ext2でいい用途なら、ext3でいいのでは? >> 643

一長一短
ext3はext2より遅い
実際比べてみればわかるよ

647 :login:Penguin:2007/02/18(日) 17:39:23 ID:PPDNN+G1
xfs_fsrがあるから、xfsをえらぶ

648 :login:Penguin:2007/02/18(日) 18:27:01 ID:N9FxkNNy
>>646
外部ジャーナルでdata=journal

649 :login:Penguin:2007/02/18(日) 18:32:23 ID:UT3ERil/
速さが欲しけりゃtmpfs、ramfsでも使ってろって

650 :646:2007/02/18(日) 18:44:04 ID:x2PO8wq2
>>648-649
>645は
> ext2でいい用途なら
と発言してるんだが

651 :login:Penguin:2007/02/18(日) 23:24:26 ID:lw5RYTmu
正直なところ ext2 や ext3 よりは 速度面から考えたら
ReiserFSやらXFSやらの最新のFSを使いたいが、
結局、ext2 or 3 よりも安定性が低いんだよね。

652 :login:Penguin:2007/02/18(日) 23:29:23 ID:9TlqakwN
>>651
そんなことはない

653 :login:Penguin:2007/02/18(日) 23:33:14 ID:9TlqakwN
現時点に限ればReiserFSやXFSは安定性で勝っても劣ることはない

654 :login:Penguin:2007/02/18(日) 23:43:45 ID:QuRETY6G
Reiserが安定しなかったのは過去のこと、っていうのはわかる。
でも今ext2や3よりも安定しているのを求めている以上、
どういう理屈で、どの程度安定しているのかという情報は欲しい。
でないと水掛け論になりかねん。

655 :login:Penguin:2007/02/18(日) 23:44:49 ID:pYLNl7kF
xfsってもう十分実用になってるの?
数年前にreiserfs3で入れてからしばらく情報集めてなかったんだけど、
次に入れる時にext3に戻るかxfsにするかで迷ってる。

656 :login:Penguin:2007/02/19(月) 00:24:37 ID:assudzzV
>>654
> どういう理屈で、どの程度安定しているのかという情報は欲しい。
そんな事ができる人がどこにいますか?

私が言えるのは、自分の経験とこのスレの過去ログぐらい
ext2や3で被害にあう方が圧倒的に多い

>>655
十分実用になってます

657 :login:Penguin:2007/02/19(月) 01:08:42 ID:iBUqDm6A
xfs って、うちの会社のサーバーじゃオーバースペックな気がしてなぁ。
だからといって ext3 じゃトロいしなぁ。
というわけで、ReiserFS を使ってるんだよなぁ。
何だかなぁ……。

658 :login:Penguin:2007/02/19(月) 01:29:24 ID:97QHaRcu
>xfs って、うちの会社のサーバーじゃオーバースペックな気がしてなぁ。
これってどういう意味でしょう?
そのサーバーで使うには、負荷が高いという意味?(機械にとって)
その用途で使うには、機能が過剰という意味?(目的に対して)
それとも、管理が面倒すぎるっていう意味?(人にとって)

659 :login:Penguin:2007/02/19(月) 01:38:10 ID:l8ESTcsS
>>656
でもReiserで過去に失敗した人がReiserよりext、って言ってるわけでしょ。
それは>>620の問題があって、それに引っかかった人だと思うけど。
過去の経験を補強する情報がなければ結局水掛け論になるよ。
たとえばSunなんかはZFSの信頼性は99.9999……%云々っていってるけど、
ああいう形で信頼性を示せれば信頼性に関する議論も進むし、
そういう情報が欲しいといってるわけで。
(その信頼性を実現する仕組みに関する簡単な解説でもつけてくれればなおいい)

660 :login:Penguin:2007/02/19(月) 01:57:51 ID:jkHVDhT6
Sunの99.9999...なんてマーケットトークに決まってんじゃん。
実装バグで起きる問題の確率が事前予測できるわけない。
まあ、商用製品で正式採用する以上、テストパターンを網羅して
走らせるだろうから、最終的には上の信頼性だろうけど。

安全性設計の部分だけに評価して各FSを比較できないもんかなぁ。
あとは実装容易性の評価とか。


661 :login:Penguin:2007/02/19(月) 02:18:24 ID:HPwpnWaB
信頼性って評価難しいよなあ。
参考までに俺は各種サーバ(主にファイルサーバー)約10台
計約50TBを xfs で使ってる。信頼性に関していえば ext3 と比べてどっ
ちが良いかはよく分からない。性能など信頼性以外の面では xfs
が優れてだと思う。freeze もできるし。

話題の ZFS についても壊れるというのはまだ経験ないけど、ファイル
システム関連の操作が引き金になってOSが固まるとい現象はよくある。
今日も zfs destroy の最中に固まった。

662 :login:Penguin:2007/02/19(月) 03:03:56 ID:/3Lv0pp1
HDDの信頼性測定とかは1000台近くを何日か稼動させて
故障台数とポワソン分布で計算するんだってさ。よくわからんけど。
fsみたいな故障しにくいものを測定するにもそんなやり方でやるのかね?

663 :login:Penguin:2007/02/19(月) 07:40:17 ID:AMxoEq8N
>>662
それはMTBFあたりを出すときのやりかただろ?


664 :login:Penguin:2007/02/19(月) 12:11:33 ID:gCr74owG
ポワソン分布でなにかまずいのか?

665 :login:Penguin:2007/02/19(月) 12:37:56 ID:2Z7LmjBo
カイ2乗検定とかじゃないの?


666 :login:Penguin:2007/02/19(月) 14:22:21 ID:7bxVjLSa
最近、GoogleがHDDの故障率のレポだしてたけど
あれ各種ファイルシステムでレポ欲しいよなあ

667 :login:Penguin:2007/02/19(月) 14:31:37 ID:HPwpnWaB
ext2 の上に GFS (google file system)っていうのは昔の話?

668 :656:2007/02/19(月) 17:03:47 ID:PUnHazDt
>>659
要求しているのは、信頼性の定量評価でしょう
それなら、検証するための条件を実際に出してほしい
それは無理でしょう

669 :login:Penguin:2007/02/19(月) 19:17:04 ID:assudzzV
>>659
> でもReiserで過去に失敗した人がReiserよりext、って言ってるわけでしょ。
> それは>>620の問題があって、それに引っかかった人だと思うけど。

例えばこのReiserFSのバージョン間の互換性の問題。
これを信頼性の比較テストで見つける事は非常に難しい。

670 :login:Penguin:2007/02/19(月) 19:21:43 ID:2Z7LmjBo
へーそんなに互換性低いんだ。
Linux2.4の頃からずっと、reiserは3.6で止っていて大丈夫だと思ってた。


671 :login:Penguin:2007/02/19(月) 19:32:34 ID:S8QS6vkZ
3.5の時代だろ。

672 :login:Penguin:2007/02/19(月) 19:39:45 ID:assudzzV
>>670
2.2カーネル+ReiserFSパッチと2.4カーネルにマージされたReiserFSとの互換性
2.4カーネルでマウントできなかった

673 :login:Penguin:2007/02/19(月) 19:50:01 ID:2Z7LmjBo
なんだ、そんな昔の話かよ。
しかも、カーネルに統合されていない時代の話しだし。


674 :login:Penguin:2007/02/19(月) 19:56:23 ID:assudzzV
>>673
2.4カーネルは安定性に大きな問題があって、長期間に渡って2.2カーネルと併用されてた

675 :login:Penguin:2007/02/19(月) 20:00:02 ID:2Z7LmjBo
それは違うだろ。
はるか昔から、安定版、現行版、開発版という体系だったんだから。


676 :login:Penguin:2007/02/19(月) 20:02:34 ID:assudzzV
ディストリでの2.4の採用が大きく遅れたんだよ

677 :login:Penguin:2007/02/19(月) 21:34:21 ID:S8QS6vkZ
676のいうディストリを挙げてくれないか?

678 :login:Penguin:2007/02/19(月) 22:08:11 ID:assudzzV
カーネル2.4のリリースが2001年1月10日
SUSEはすぐに取り入れ2001年2月
Turbo Linuxは少し遅れ、2001年5月
Red Hatは1度2.4のリリースを見送り2001年9月
保守的な
Vine2002年4月
Debian2002年7月

679 :login:Penguin:2007/02/19(月) 22:10:48 ID:hoyrNl8c
2.4ではVMがなかなか安定しなかった希ガス。
Linusがファビョって途中でVM入れ替えてた希ガス。

680 :login:Penguin:2007/02/19(月) 22:17:29 ID:S8QS6vkZ
>>678
で、2.6の場合は?

681 :login:Penguin:2007/02/19(月) 22:24:08 ID:assudzzV
>>680
自分で調べてくれないか?
2.4は肝心のRed Hatがリリースを見送ったのが痛かったんだよ

682 :login:Penguin:2007/02/19(月) 22:34:50 ID:ccsrEDDl
ID:S8QS6vkZは典型的な知能障害の教えてくん。放置推奨。

683 :login:Penguin:2007/02/19(月) 22:50:28 ID:S8QS6vkZ
しゃーねーなー、一度だけだぞ。
2.6.0リリース: 2003/12
SUSE: 2004/3(2.6.4)
Turbo: 2003/10(2.6.0test5)
RHEL: 2005/2(2.6.9)
FC:2004/5(2.6.5)
Vine:2006/11(2.6.16)
Debian: 2007/?(2.6.18)

2.6と比較して、2.4が取り立てて遅れたとはいえない。
ディストリ=レッドハットしか頭にない誰かさんには
けしからんかもしれんがね。

684 :login:Penguin:2007/02/19(月) 23:06:46 ID:assudzzV
> 2.6.0リリース: 2003/12
> SUSE: 2004/3(2.6.4)
> Turbo: 2003/10(2.6.0test5)
> FC:2004/5(2.6.5)

保守的なディストリ以外はすぐに入ってるじゃないか

685 :login:Penguin:2007/02/19(月) 23:15:09 ID:YjhinaPB
2.6 の方が断然採用が遅れてるのに目を向けられない ID:assudzzV

686 :login:Penguin:2007/02/19(月) 23:15:54 ID:WFcsg+zG
>>661
誰かファイルシステムの信頼性テストアプリ書いたら面白そうだね。
以下の処理をランダム(どのファイル/ディレクトリ、どの処理、何回)で実行。
作成するファイル名やディレクトリ名もランダム。

ファイル読込、ファイル書込、
ファイル作成、ファイル削除、ファイル移動、
ディレクトリ作成、ディレクトリ削除、ディレクトリ移動。

他にもメモリをぎりぎりまで使ってる状態でのテストや、
LoadAverageが10超えてる状態でのテストや、
上のテストを複数のボリュームに大して同時実行とかもやってみるといいかも。

687 :login:Penguin:2007/02/19(月) 23:19:08 ID:assudzzV
>>686
書き込み中の電源断は必須項目だよ

688 :login:Penguin:2007/02/19(月) 23:52:06 ID:iBUqDm6A
>>686
その仕様でオマイが書いてクレ

689 :login:Penguin:2007/02/19(月) 23:58:52 ID:assudzzV
>>686
信頼性を「定量」するんだからな
ちゃんと何が起これば何点という重みもつけてくれよ

690 :login:Penguin:2007/02/20(火) 00:46:37 ID:xMR490Gf
>>668
654=659=俺。
654では定量評価と書いてないので納得してくれ。
定量評価が無理なのには同意する。

691 :login:Penguin:2007/02/20(火) 01:06:30 ID:dBqV9fZF
各ファイルシステムでランダム書き込みテスト中にシャットダウン。
これを10万回位して有意な差があるかどうかで定量評価できない?

あとは実験ではなく書き込みアルゴリズム部分を抜き出して
相互比較するくらいか>安全性の比較


692 :login:Penguin:2007/02/20(火) 01:25:21 ID:mknq5eEf
10万回って… 何年かける気だよ

693 :login:Penguin:2007/02/20(火) 01:44:43 ID:jhKEG9sP
>>691
教祖にでも頼んだら?

694 :login:Penguin:2007/02/20(火) 01:59:56 ID:RrNcxD36
>>687,691
電源断したら、10回に1回ぐらいでHDDが物理的に死ぬんじゃないかな。
昔UPS買う金もなかった頃、停電で5台のサーバ中1個ぐらいHDD壊れてたし。

695 :login:Penguin:2007/02/20(火) 03:52:27 ID:ER7Tw+jP
>>647
それは言える

696 :login:Penguin:2007/02/20(火) 04:13:03 ID:DkD2TaWO
Google File Systemってどんなの?

697 :login:Penguin:2007/02/20(火) 10:01:01 ID:lQlBrHwX
Gmailをバックエンドとしてマウントする、たんなるネタ。

698 :login:Penguin:2007/02/20(火) 10:11:56 ID:mknq5eEf
それgmailfs

699 :login:Penguin:2007/02/20(火) 15:39:52 ID:w1qTNq/E
まあ普通にやるならポア損だろう

700 :login:Penguin:2007/02/20(火) 16:53:19 ID:u7PVyFqb
>>696
つ[http://216.239.37.132/papers/gfs-sosp2003.pdf]
ファイルシステムとしての機能は実装されているが、このスレで話題にするような
ものとはレイヤが違う希ガス

701 :login:Penguin:2007/02/20(火) 17:04:16 ID:mknq5eEf
「POSIX互換なファイルシステム総合スレ」にすればいいのかな。

702 :login:Penguin:2007/02/20(火) 19:36:37 ID:dgNADH13
>>694
> 電源断したら、10回に1回ぐらいでHDDが物理的に死ぬんじゃないかな。

何でそんなに死ぬんだ?

703 :login:Penguin:2007/02/20(火) 19:47:27 ID:/AXgYpgH
電源断が理由で起動できなくなった時に俺も物理的に壊れたと思ってた事があったw

704 :login:Penguin:2007/02/20(火) 19:53:47 ID:8d1pfd9r
むかーしのHDDは電源ぷっつんで、死んでたけどね。


705 :login:Penguin:2007/02/20(火) 20:25:47 ID:trVnBvGy
それは20MBのHDDの時代だろwww
流石に、100MB超えたらヘッドの待避はしてるから。

706 :login:Penguin:2007/02/20(火) 21:00:36 ID:gPb9g80v
namesysでそんなテストやってなかった?
速度比較だけど内容はそんな感じだったよ。
しかし、一回でもエラーがあるようならファイルシステムとしては致命的だよね。
書き込み途中のデータが電源断で失われるのは物理的に回避不可だからUPSなんかに頼るべきだけど、
それ以外のエラーはあってはいけないよね。

707 :login:Penguin:2007/02/20(火) 21:25:48 ID:RrNcxD36
>>702,704,705
40〜80GBぐらいのHDDだったはず。
ひょっとしてかなり運が悪かったのかな?

708 :login:Penguin:2007/02/20(火) 21:28:09 ID:pQclaEp+
>>706
> 書き込み途中のデータが電源断で失われるのは物理的に回避不可だからUPSなんかに頼るべきだけど、
> それ以外のエラーはあってはいけないよね。

ファイルシステムが逝く大きな原因の、書き込み中の電源断をテストから外したとする
そのテストで良い結果が出たら、信頼性のあるファイルシステムだと誰が思うんだ?

709 :login:Penguin:2007/02/20(火) 21:28:56 ID:PbWkwsqa
いぁ、家庭で使ってるようなあれで、HDDに書き込みしてないのがほぼ確認できた
時点で電源落としてればほとんど問題はないだろうし、サーバーで使ってて
いつ何をやってるのかよく分からない状態で電源が落ちればHDDやられるだろうし、
ケースバイケースなんじゃね?


710 :login:Penguin:2007/02/20(火) 21:33:42 ID:yxMMBa/L
/dev/sdX を read,writeするプログラムを書いて
電源斷すれば、ハードのせいかファイルシステムのせいか
はっきりするだろ?

711 :login:Penguin:2007/02/20(火) 22:08:55 ID:j2utBboh
書き込み中の電源断テストをしないで、いったい何をテストするのやら

712 :login:Penguin:2007/02/20(火) 22:20:07 ID:joRKZnqH
> 流石に、100MB超えたらヘッドの待避はしてるから。

根拠をきぼんぬ。

713 :login:Penguin:2007/02/20(火) 22:27:21 ID:ER7Tw+jP
電源断は本当に壊れたら困るから、IDE のケーブルを抜くってのは?

714 :login:Penguin:2007/02/20(火) 22:31:41 ID:pQclaEp+
ジャーナリングファイルシステム自体が
書き込み中の電源断に備えてジャーナルをせっせと書いているわけだろう
これをテストしないでファイルシステムの信頼性テストができるの?

715 :login:Penguin:2007/02/20(火) 22:34:58 ID:j2utBboh
そうそう

716 :login:Penguin:2007/02/20(火) 22:40:09 ID:8d1pfd9r
>>705
うん。ストップボタンがついてるやつな。


717 :login:Penguin:2007/02/20(火) 23:02:15 ID:RrNcxD36
>>714
なるほど。
ケーブル抜くとか物理的な方法だと何回もテストが大変だから、
強制アンマウントとかできないかな?

718 :login:Penguin:2007/02/20(火) 23:10:14 ID:dBqV9fZF
USBでアナログスイッチ制御してバスをいきなり切り離したりすれば
いいんじゃない?復帰させる時はバスつなぎ直してからモジュールを
リロード。


719 :login:Penguin:2007/02/21(水) 01:22:44 ID:WfQ7wulD
それだと既にHDDのキャッシュに入ってる分が安全に書き込まれてしまうかもしれない。

720 :login:Penguin:2007/02/21(水) 02:39:41 ID:n6EMsHwD
IDEのケーブル抜くのは、HDDのディスク面への傷はつかないかも知れないが、
インターフェイス部分を電気的に壊すかもしれないぞ。

それだったら、リセットボタンを押して強制リセットの方がハードウェア的に安全だと思う。
少なくとも強制リセットでXFSはFSが壊れたことがある。

721 :login:Penguin:2007/02/21(水) 12:12:37 ID:HkfANAOw
スループットなら iozone があるけど、
メタデータ部分に関するストレステストのようなものは
広く使われているものってあるかな?

722 :login:Penguin:2007/02/21(水) 12:22:02 ID:yYJCU+QD
まずは、ファイルシステムが壊れた、の定義からだな。
そうして話はループする。

723 :login:Penguin:2007/02/21(水) 12:26:26 ID:9eNEo15t
つーか書き込み中でもHDDのヘッドは浮いてますぜ。

724 :login:Penguin:2007/02/21(水) 12:35:51 ID:PCwOt2tc
IDEじゃダメなんじゃないの?
IDEはハード的に厳密な書込み保障してないんだろ?


725 :login:Penguin:2007/02/21(水) 12:37:05 ID:9eNEo15t
そのためのUPSだろ?
Linux鯖でシャットダウン用UPSなしはありえないだろ。常識的に考えて。

726 :login:Penguin:2007/02/21(水) 12:38:32 ID:AEAE1/jQ
ループしすぎ

727 :login:Penguin:2007/02/21(水) 12:40:11 ID:PCwOt2tc
LinuxはVFSが腐ってるから。


728 :login:Penguin:2007/02/21(水) 12:41:14 ID:2SjRgw4k
VFSって何?

729 :login:Penguin:2007/02/21(水) 12:45:01 ID:z+QDRw32
掃除のおばちゃんがUPSの後ろからサーバーのコンセントを引っこ抜いちゃった時を想定してテストするんだよ。

730 :login:Penguin:2007/02/21(水) 12:46:34 ID:5Xqck6zb
???

731 :login:Penguin:2007/02/21(水) 14:26:01 ID:Un3jNJTn
1他のファイル書込み処理中のトラブルで既存ファイルが壊れるのはファイルシステムの問題だが、
2書き込んでいる最中のデータを保障する方法はないだろう?
ところで、1の状況になるような不出来ファイルシステムでは致命的だよね?
現実的におこる可能性のあるエラーと言えば、ビット抜けなどによるデータエラーなんかだと思うのだが
エラー訂正機構などで回避するのがFSの役目じゃなかろうか。
エラー訂正できずひたすら読みなおすようではちょっとね。

732 :login:Penguin:2007/02/21(水) 14:27:26 ID:YuxiRYuL
?

733 :login:Penguin:2007/02/21(水) 16:47:07 ID:Gow8RfEW
>>724
> IDEじゃダメなんじゃないの?
> IDEはハード的に厳密な書込み保障してないんだろ?

>>553

734 :login:Penguin:2007/02/21(水) 16:55:24 ID:yYJCU+QD
$ nl linux/include/linux/ata.h |grep FLUSH
115 ATA_CMD_FLUSH = 0xE7,
116 ATA_CMD_FLUSH_EXT = 0xEA,


735 :login:Penguin:2007/02/21(水) 16:57:27 ID:Gow8RfEW
>>725
> そのためのUPSだろ?
> Linux鯖でシャットダウン用UPSなしはありえないだろ。常識的に考えて。

UPSおおいに結構
しかし、ジャーナルの話になる度にUPSの話を持ち出すのはやめてくれ

1.まずベースになるファイルシステムの信頼性を上げる
2.その上で更に安全性を確保するためUPSを使う
これが基本じゃないのか?


736 :login:Penguin:2007/02/21(水) 17:21:02 ID:PeRWIKib
ID:9eNEo15tみたいに根本的にわかってないヤシは放置しとけばいいのに

737 :login:Penguin:2007/02/21(水) 18:23:37 ID:GEUl/Slj
FS以前にVFSが腐ってるんだからUPS付けるしかないだろw
なんでも安いものには訳があるんだぜ

738 :login:Penguin:2007/02/21(水) 18:27:39 ID:Un3jNJTn
VFSってなに?

739 :login:Penguin:2007/02/21(水) 18:43:51 ID:DxVxbuVi
UPSをつけても治らない病気

740 : ◆IIiDC8JS7w :2007/02/21(水) 18:49:35 ID:HEsvAscu
xfsは独自のインタフェース等をもっていたけど、
VFSをベースにするように書き直す動きがでてきたようです。
ttp://marc.theaimsgroup.com/?l=linux-ext4&m=117164238303188&w=2


741 :login:Penguin:2007/02/21(水) 19:04:38 ID:hD5S0IpV
>>738
聞く前にググろうぜー
ttp://ja.wikipedia.org/wiki/Virtual_File_System
ttp://www.atmarkit.co.jp/flinux/rensai/fs01/fs01a.html

しかしLinuxってVFS以外はかなり良いのに、VFSが大きく足を引っ張ってるよね。
高負荷時にIOwaitに取られて、パフォーマンスがた落ちするし(とくにext3)、
私の環境だとよくファイルシステムが壊れるし。

742 :login:Penguin:2007/02/21(水) 19:08:36 ID:HkfANAOw
「腐っている」と批判される VFS を改善する
という動きはないんですか?

といっても Linux は MPI 使ったシミュレーションと
LaTeX での物書きくらいにしか使っていないので
具体的にファイルIOが高負荷になったら
生じるという問題には遭遇したことがないのですが。

743 :login:Penguin:2007/02/21(水) 19:32:46 ID:Un3jNJTn
>>741
39s 理解が深まりました。
ところで>>742も書いてるけどVFSのどの辺が悪いの?
サンはファイルシステムまわりが良いとよくいわれるけど、実感したことがないんだよね。
直接比較しにくいから「体感速度」でしかないけれど。

744 :login:Penguin:2007/02/21(水) 19:39:33 ID:DxVxbuVi
気にならなければそのままでいいんじゃない?

745 :login:Penguin:2007/02/21(水) 19:54:32 ID:AEAE1/jQ
>>742
Linus「頑張りな」

746 :login:Penguin:2007/02/21(水) 19:56:24 ID:4ZGq/uco
UPS、UPSってループしすぎ
UPS使ったらFSの問題は修正する必要がなくなるのか?

747 :login:Penguin:2007/02/21(水) 20:05:21 ID:834Qq+xw
>>742
改善しようとして入る大きいバグよりは、
現状の踏む確率の低いバグの放置を選んでいる、と前スレで見た気がする。

>>746
んなわけない。
kernel(fs)の話なのにUPSを持ち出すほうがアホ。


748 :login:Penguin:2007/02/21(水) 20:12:58 ID:9eNEo15t
なんでUPS持ち出されると火病るんだよwww
現状のKernelがしょぼいからHWでその穴埋めをしてるだけの話だろw

749 :login:Penguin:2007/02/21(水) 20:15:34 ID:yt14huen
kernelがしょぼいならNexenta使えばいいじゃない

750 :login:Penguin:2007/02/21(水) 20:23:40 ID:sObj1DzR
最近はFS<->DeviceDriverは、キャッシュフラッシュ機構を伴ったfs/deviceだとちゃんとフラッシュするようにしてるとオモタ。
user<->vfs<->fsはここが最近かつ長い論議になっているな
http://groups.google.com/group/linux.kernel/browse_frm/thread/e6e6c02f1c62407f

O_DIRECTっつーキャッシュを使わないフラグの話なんだが、O_SYNCとかもからんでくる。
rawデバイスへのIOなら意味はあるかもしれないけど、fsレベルだとkernelがする仕事いろいろあるのでどうかねぇって感じかね。

>>741
kernelとioスケジューラとmount option何?

751 :login:Penguin:2007/02/21(水) 20:30:57 ID:R1KNdqH1
低脳の俺じゃ話についていけん、離脱する。

752 :login:Penguin:2007/02/21(水) 20:33:24 ID:DxVxbuVi
>>748
穴埋めきれてないから

753 :login:Penguin:2007/02/21(水) 20:40:25 ID:9eNEo15t
>>752
BSDに転向しま〜す

754 :login:Penguin:2007/02/21(水) 20:55:45 ID:yYJCU+QD
>>750
raw deviceにつづいてO_DIRECTも無くそうって話が確かその後にあったとおもう。
どちらも移植性以外にメリットがなく、O_DIRECTを使わないプロセスとの
キャッシュの整合性をとるのが難しくて、デバイス全体(/dev/sda)のopen時
くらいしか意味がなく、それだったらSG_IOつかえばいいじゃん、って話。

755 :login:Penguin:2007/02/21(水) 21:06:53 ID:hD5S0IpV
>>750
kernel 2.4.21-37.ELsmp
mount option は defaults,noatime
IOスケジューラはkernel 2.4だから選択不可

kernel 2.6ではまだ高負荷サーバの運用経験なし。
たぶん2.6にすれば、だいぶIOwait解消するとは思うけど。

756 :login:Penguin:2007/02/21(水) 21:14:48 ID:yYJCU+QD
(´-`).。oO(2.4.20のリリースは2002/11/29....)

757 :orz:2007/02/21(水) 21:15:32 ID:yYJCU+QD
(´-`).。oO(2.4.21のリリースは2003/06/13....)


758 :login:Penguin:2007/02/21(水) 21:28:59 ID:AEAE1/jQ
>>755
  i     ,、 n て'' ノノ    ヾ   !
  i    ノノノ ノ ノ ''´      !  /
     j   ' ´    ノ (    ヽ |
 >-,,  /  ,,=━━・!' ,ノ━== ! ノ    だいぶIOwait解消するっていうレベルじゃねぇぞ!
 !・  ヽ |  ’ニンniii、 :::::i/ィ7iii=  i )
 \(てi iヽ   ^' ~     -'  /}    http://osdn.jp/event/kernel2005/pdf/comware.pdf
  `i_   、 \        i_    l_j   
   `┐ i    /(,,, ,n 〉   /\\
  ̄ ̄へ    ! '   T''    l |  \
   |  ! i    ン=ェェi) i ソ )        
   |  i´\! ,, -ェ`、_ン ノノ 〈
   |  |  \\,, `―''´//  |    

759 :login:Penguin:2007/02/21(水) 21:58:29 ID:PCwOt2tc
syncもすっ飛ばしてしまえば、IOwaitなんて関係ないわなw


760 :login:Penguin:2007/02/21(水) 22:08:11 ID:hD5S0IpV
>>756-758
2.6にすればパフォーマンスが上がるというのは分かってるんだけど、
メンテで1時間止めるのも難しい状態だから、いつになったら2.6に差し替えられるのか…。

761 :login:Penguin:2007/02/21(水) 23:02:44 ID:BIoIhGtz
2.6.x になってもVFSの酷さは相変わらずだよな。

762 :login:Penguin:2007/02/22(木) 00:32:09 ID:FQEhcbo4
仮想マシン使ってテストすれば
機械的問題なのかfsの問題なのかわかるんじゃないの。

763 :login:Penguin:2007/02/22(木) 00:35:02 ID:htZU4gWZ
仮想マシンがバグったらどうすんのさ

764 :login:Penguin:2007/02/22(木) 01:00:37 ID:q55utThu
>>762
それはなかなか良い案だ。
メモリ割当量とかも好きに設定できるし。

あとは誰かプログラム書いてくれる神さえいれば。

765 :login:Penguin:2007/02/22(木) 03:18:09 ID:tTU6pSfe
>>712
電源が切れたら、ゴムひもの張力でヘッドが勝手に戻る
ttp://www.youtube.com/watch?v=9eMWG3fwiEU

766 :login:Penguin:2007/02/22(木) 07:05:48 ID:FQEhcbo4
それ面白いな。ほかにもいろんなHDDの使い道が出てて面白い。
http://www.youtube.com/watch?v=yISqCAnROh8
http://www.youtube.com/watch?v=8GT2WrsCDmI

767 :login:Penguin:2007/02/22(木) 20:28:42 ID:6jPn/IKu
>>759
> syncもすっ飛ばしてしまえば、IOwaitなんて関係ないわなw

そんなことはない
ディスクのキャッシュには書き込む必要があるから、IOwaitは普通に発生するよ
syncすっとばして問題が解決するなら、なぜ2.4カーネルでこの問題が起きてるんだ?

768 :755:2007/02/22(木) 21:59:22 ID:q55utThu
>>750
よく考えたら、kernel 2.6で高負荷サーバ稼働してるの忘れてた。
kernel 2.6.9-22.ELsmp
mount option: defaults,noatime
IOスケジューラ: cfq

postfixでメルマガ配信してると、以下ぐらいの負荷になってる。
kernel 2.6でもiowait発生してる。

eth0 traffic: 2Mbps
LoadAverage: 8
CPU usage: system 20%, user 20%, iowait 100%, idle 60%
Processes数: 230
Fork rate: 30〜50
context switches: 4k
inode table size: 70k
open inodes: 65k

769 :login:Penguin:2007/02/22(木) 22:27:15 ID:/q5UJHT3
それいつの時代のカーネルだよw

770 :login:Penguin:2007/02/22(木) 22:50:01 ID:xsGcVMRo
>768
そのマシンのスピンドルは幾つですか?

771 :login:Penguin:2007/02/22(木) 22:57:22 ID:AXb8oIxu
2.6.9-22.ELsmpでググると2番目に
http://bugs.centos.org/view.php?id=1064
が速攻出てくるけど。
なんかそのカーネルかディストリがおかしいんじゃねーの?

772 :login:Penguin:2007/02/22(木) 22:57:55 ID:q55utThu
>>770
メインにSATA 240GB(RAID 1)で、バックアップ用にSATA 160GB。

773 :login:Penguin:2007/02/22(木) 22:58:53 ID:xsGcVMRo
つか、iowait100% にしてて、ど〜しよ〜なんて言ってる時点で向いてないね。
solarisいれてCTCにでもサポートしてもらったら?


774 :login:Penguin:2007/02/22(木) 23:03:41 ID:AXb8oIxu
もっと突っこんだのがあった。特定のverだけおかしいぽい。
http://www.vbulletin.com/forum/showthread.php?t=171071

775 :login:Penguin:2007/02/22(木) 23:17:55 ID:q55utThu
>>771,774
ほー、RedHatのリリースノートには書かれてなかったから、気づかなかったよ。
今度、メンテ承諾もらって、updateしてみるかな。ありー。

776 :login:Penguin:2007/02/23(金) 17:05:00 ID:s5HiNLYj
http://www.ntfs-3g.org/
NTFS-3G Read/Write Driver が 1.0にバージョンアップしてる。

http://www.ntfs-3g.org/quality.html
書込みも問題なさそうだ。

777 :login:Penguin:2007/02/25(日) 04:35:45 ID:hhkRX3pL
今日から /home に ext4dev -extents を使い始めました。
お世話になります。よろしくお願いします。

778 :login:Penguin:2007/02/25(日) 12:32:09 ID:1UDdobUo
FreeBSDで使っていたUFS2のHDDがあるのだけど、これを Linuxで使う場合、
UFS2のままmountとして使える?
また、もしできた場合、安定性や速度面の問題ってある?

とりあえず、Gentooで使うつもりなんだけど、kernel はできるだけ新しいのを
使う予定。

779 :login:Penguin:2007/02/25(日) 13:01:10 ID:RNf5xhry
>>778
http://vivian.mysite.ddo.jp/modules/newbb/viewtopic.php?topic_id=14&forum=5
速度や安定性は人柱になってくれ
ソース少ないから

ソフトアップデートは無理だろうが、非同期書き込みのはずなのでext2ぐらいの速度?
漏れにはわからね

780 :login:Penguin:2007/02/25(日) 13:08:10 ID:RNf5xhry
一つ気が付いたんだが、安定性は問題ありじゃねえ?
非同期書き込み(未確認)、ソフトアップデート無(未確認)、ジャーナル無で電源断の場合、
高確率でFSの不整合が起きると思う
その場合fsckができないんじゃない?

781 :login:Penguin:2007/02/25(日) 21:36:31 ID:XSSbnSFj
>>780
Linuxのext2のfsckはそういう状態からでもかなりの確率で無事に
復活するように作ってあるけど、ufsのfsckは割と根性無しなんですよねえ。

782 :login:Penguin:2007/02/25(日) 21:44:52 ID:eNvns68U
>>747
| 改善しようとして入る大きいバグよりは、
| 現状の踏む確率の低いバグの放置を選んでいる、と前スレで見た気がする。

2.7のような「開発版」kernelが出てこない限り、大きな変更は出来ないだろ。




783 :login:Penguin:2007/02/25(日) 21:56:06 ID:eNvns68U
>>775
| 今度、メンテ承諾もらって、updateしてみるかな。ありー。
テスト環境で試すんだよな、まずは。

784 :login:Penguin:2007/02/25(日) 22:02:07 ID:mGRzOabw
やつの性格からして無理だろ。

785 :login:Penguin:2007/02/25(日) 23:26:14 ID:Wbhx9dns
>>782
2.6は安定版と開発版を兼ねてるけどな。
というか開発版を作ると安定まで時間かかるから
一緒にしてる時点で問題な気がする。

786 :login:Penguin:2007/02/26(月) 02:03:12 ID:yHQGbhTx
>>779
>>780
>>781
レスありがとう

FreeBSDとLinuxでデュアルブートをしたいと考えているんだけど、
ufsが安定しないならちょっと面倒かな。

787 :login:Penguin:2007/02/26(月) 09:02:34 ID:Uic3Hco6
スピードもメディア使用効率もREISERが一番だと思うんだが
ほかのFS使うメリットってなに?

788 :login:Penguin:2007/02/26(月) 10:09:07 ID:dEzBE57o
Reiser が怖いという人もいるんじゃないか?

789 :login:Penguin:2007/02/26(月) 10:12:27 ID:0OlI08HE
>>787
今後の開発継続に対する信頼性とか。
さすがにRaiserみたいに、メインの開発者が被訴訟中とか不安よ。

790 :login:Penguin:2007/02/26(月) 10:25:38 ID:K+lcaOP8
トラックナンバーが高いというのが問題。

791 :login:Penguin:2007/02/26(月) 10:27:53 ID:K+lcaOP8
低いだ。orz

792 :login:Penguin:2007/02/26(月) 10:44:54 ID:4rytkNB2
>>789
現行の物を使う分にはディストリビューターがサポートするんだし、問題ないべ。

793 :login:Penguin:2007/02/26(月) 10:55:32 ID:h0u2mbnQ
>>792
Reiser3を使い続けるのならそだね。いまさら大きなバグとか出てこないだろうし。
問題はReiser4。fs自体の開発もそうだし、kernelにマージされていないから、
それに追随していくだけでも面倒だし。

794 :login:Penguin:2007/02/26(月) 11:05:51 ID:K+lcaOP8
>>792,793
でも、この前SUSEのカーネルメンテナーがもうやめって言ってたから、
ほとんど誰もメンテできないに等しいのでは?
reiser3の大きなバグは公称16TBサポートなのに、実際には8TBしか
使えないことかな。

795 :login:Penguin:2007/02/26(月) 13:09:44 ID:Uic3Hco6
それは実用上差し支えあるのかな?
reiser3は実質バグフリーに近い状態だからメンテが重要とは思えないのだけど。
reiser4は未完成品だから カーネルにマージされないのはある程度しかたない。
手軽に使いたければmmカーネルという道はあるんだし。
というわけでreiser3を使わないとすれば、理由は根拠希薄な不安感というしかないのじゃなかろうか。

796 :login:Penguin:2007/02/26(月) 13:12:31 ID:wkQWJiQy
ファイルシステムは壊れるような使い方をするソフトやユーザーが悪い

797 :login:Penguin:2007/02/26(月) 13:53:32 ID:V6eujtdB
ソフトやユーザーが壊れるような使い方をして壊れてしまうファイルシステムが悪い


798 :login:Penguin:2007/02/26(月) 14:16:54 ID:86SdDkQo
全部俺が悪い

799 :login:Penguin:2007/02/26(月) 15:11:20 ID:WnZHn5Z+
>>797
ファイルシステムのせいで次々に壊れていくユーザーたちの様子を想像した

800 :login:Penguin:2007/02/26(月) 15:43:28 ID:w3Q8mpHC
8TBも16TBも、もう見えている制限やね

801 :login:Penguin:2007/02/26(月) 20:08:22 ID:Vz7FGpwz
796 名前:login:Penguin[sage] 投稿日:2007/02/26(月) 13:12:31 ID:wkQWJiQy
ファイルシステムは壊れるような使い方をするソフトやユーザーが悪い

797 名前:login:Penguin[sage] 投稿日:2007/02/26(月) 13:53:32 ID:V6eujtdB
ソフトやユーザーが壊れるような使い方をして壊れてしまうファイルシステムが悪い

当然あるべき姿は後者だわな

802 :login:Penguin:2007/02/26(月) 21:24:40 ID:Uic3Hco6
つまりライザーでォケということだね?

803 :login:Penguin:2007/02/26(月) 22:43:55 ID:Vz7FGpwz
俺もReiserがいいと思う

804 :login:Penguin:2007/02/26(月) 22:46:19 ID:4rytkNB2
現状reiserfs一択

805 :login:Penguin:2007/02/26(月) 22:47:17 ID:nOHFybZp
reiserfs がクソということが決定したようですね

806 :login:Penguin:2007/02/26(月) 22:54:53 ID:K+lcaOP8
>>795
実用上という点では、実際に問題にぶつかったかどうかで、
ファイルサイズの制限はうちが喰らった問題だし、
セキュリティー上の問題は皆が困るしね。

メンテナ不在というのは、モートンたん以外にパッチの
拾い手がない今の状態を言ってるの。

807 :login:Penguin:2007/02/26(月) 23:20:51 ID:Vz7FGpwz
>>806
カーネルにマージされている以上、重要なバグはメンテされるよ
サイズの問題はバグでもあるが、それ以上に仕様自体が限界の部分が大きい
スケールが必要な人は自分に必要なFSを選ぶべき

808 :login:Penguin:2007/02/26(月) 23:22:09 ID:VI1vlLsi
>>798
神!


809 :login:Penguin:2007/02/27(火) 00:42:12 ID:y0/eKGgU
FUSE/ZFSっていまんとこどうなの?
使えそうな感じ?

810 :login:Penguin:2007/02/27(火) 00:51:39 ID:7MHGvYSv
>>807
重要なバグが出たら reiserfs は切り離されるんだな。はやく切り離されないかなぁ。

811 :login:Penguin:2007/02/27(火) 00:54:41 ID:EcvkLdsW
ZFSがFUSEで使えてもちっともうれしくないだろ。
NTFSのように安全に読み書きしさえできればいいってもんじゃないし。


812 :login:Penguin:2007/02/27(火) 02:18:32 ID:6Dn1rZSi
>>798
Hansたん?

813 :login:Penguin:2007/02/27(火) 02:19:22 ID:v2vfrl1x
>>810
そう簡単なもんじゃないよ
安定版カーネルに、
運用上の障害になるような変更を加えるのはかなりの事態だからな

814 :login:Penguin:2007/02/27(火) 04:19:49 ID:7MHGvYSv
2.6 系のバージョンアップの課程であっさりと pc98 コードは削られてけどな。
アーキテクチャ丸ごと消滅だぜ。
reiserfs は回復不能なバグが発見された後さっさと消えてほしい。ソースコードの容量の無駄。

815 :login:Penguin:2007/02/27(火) 06:01:09 ID:Hmix+MHb
それは感情的な問題だね

816 :login:Penguin:2007/02/27(火) 09:20:39 ID:bjHPzH3M
>>814
それはやる気の問題で削られただけだろ

817 :login:Penguin:2007/02/27(火) 11:38:07 ID:xhenCEko
reiserfsのメンテナにやる気があるのか?

818 :login:Penguin:2007/02/27(火) 16:21:39 ID:Hmix+MHb
ライザーは現行ハードウェアで現役だがPC98はどうかな?
ということでしょ。

819 :login:Penguin:2007/02/27(火) 17:06:08 ID:odrUm09C
結局、妻殺人犯ということでいいの?

820 :login:Penguin:2007/02/27(火) 17:09:24 ID:+pV1q2FN
ユダヤの陰謀

821 :login:Penguin:2007/02/27(火) 19:26:19 ID:uh9dWXID
Linuxを不安定なままにしておきたいと一番強く思ってるのはIBMなんじゃないのか

822 :login:Penguin:2007/02/27(火) 20:51:31 ID:v2vfrl1x
なぜ?
Linuxをここまで大きくしたのはIBMだろう

823 :login:Penguin:2007/02/27(火) 20:53:56 ID:me+OilzU
コントロールの元におきたいだろうな

824 :login:Penguin:2007/02/27(火) 22:51:16 ID:y0/eKGgU
>>822
でもねーんじゃねーの?
どっちかというとIBMの法則が炸裂してOS/2化してる気がするが

825 :login:Penguin:2007/02/27(火) 23:13:51 ID:v2vfrl1x
>>824
IBM抜きで今ほどの勢力になれたのかな?
ただし、IBMはLinuxをつまらなくしたとは思う

826 :login:Penguin:2007/02/28(水) 00:16:44 ID:bvIKc0cW
現状のLinuxについてIBMの貢献はそれほど大きくないし
これからもそうだと思う。
金の成る木だから寄ってきてるに過ぎない。Novellにしてもそう。
でも使えるリソースは使うに限る。

827 :login:Penguin:2007/02/28(水) 00:49:06 ID:yoQyE7e7
IBMはSolarisを駆逐したかったんだろ。
Solarisと心中できるなら、AIXくらい死んでもいいと。


828 :login:Penguin:2007/02/28(水) 02:56:37 ID:RS+QnH8S
>>826
Linuxの開発に対してのIBMの貢献はそんなに大きくないけど
普及に対しての貢献は、とてつもなく大きいよ。
その結果として、開発者のが集まったという面もあるし。

829 :login:Penguin:2007/02/28(水) 07:43:52 ID:EqW3aXe+
何の話し?

830 :login:Penguin:2007/02/28(水) 10:31:12 ID:JI+9to3r
>>817
NovellのメンテナがブータレてSUSEのデフォルトから外されたけど、
メンテは継続するするという話だったような。

831 :login:Penguin:2007/02/28(水) 13:39:23 ID:ozar7fRM
>>830
そんなの出来る人材がほいほい居るとも思えんが
・・・・いまのNovelにね。

202 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)