06/11/25 21:24:41 BgxtdIS9
過去スレ
01 ｽﾚﾘﾝｸ(linux板)
02 ｽﾚﾘﾝｸ(linux板)
03 ｽﾚﾘﾝｸ(linux板)
04 ｽﾚﾘﾝｸ(linux板)
05 ｽﾚﾘﾝｸ(linux板)
2:login:Penguin
06/11/25 21:30:24 i4K5FFzZ
ext4
URLﾘﾝｸ(www.bullopensource.org)
reiserfs/reiser4
URLﾘﾝｸ(www.namesys.com)
xfs
URLﾘﾝｸ(oss.sgi.com)
jfs
URLﾘﾝｸ(jfs.sourceforge.net)
nfs
URLﾘﾝｸ(nfs.sourceforge.net)
ntfs
URLﾘﾝｸ(linux-ntfs.sourceforge.net)
fuse
URLﾘﾝｸ(fuse.sourceforge.net)
3:login:Penguin
06/11/25 21:34:37 5Uh5FC/9
＜○√ 棒人間。本スレの主役。
∥ 格好いい事言ってみんなを逃がそうとするがすぐ死ぬ。
くく お調子者だが正義感溢れる熱血青年。一番数が多い。
＜●√ ブラック。棒人間の親友。
∥ 棒人間とほぼ互角の力を持つ頼りになる男。
くく 棒人間とともに糞スレを支えるぞ。
＜★√ スターマン。棒人間とは互いに競い合うライバル同士。
∥ かなりの力を持つが天井には敵わない。
くく
＜□√ たまに出てくる四角顔。天井を支えやすいらしい。
∥
くく
4:login:Penguin
06/11/25 21:36:48 5Uh5FC/9
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＜○√ ＜どんなに抗っても運命は変えられないかもしれない
∥ だが、そこに生きた証だけは違うと信じたい・・・
くく
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＜○√
ﾆｬｰ ∥
hoくく
ｽﾘｽﾘ…
i
| i! | l| i! | ＜にゃああああああああ！！
＿l|i|_|＿li|＿＿l!＿＿liil＿＿＿li|＿＿l!＿＿
5:login:Penguin
06/11/25 23:48:11 JuMuth85
で、全スレ最後のネタだが、rsyncが悪いのか？
6:login:Penguin
06/11/26 00:02:55 uAPikEUp
そのネタを前スレの梅ネタに汁
7:継続中
06/11/26 16:55:21 0hxeOY4W
967 ：login:Penguin：2006/11/24(金) 08:20:00 ID:DPMfSxwp
誰か実験で一つのパーティションに300万ファイルぐらい置いて、
毎日別のパーティションにrsyncでバックアップするのの実験やってみない？
RHEL4のメールサーバでext3使ってると１～３ヶ月で、
バックアップ先のファイルシステム壊れ出すよ。
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 ｘ86_64)とディスク32玉しか確保できなかった。
kernel2.6.19-ｒｃ6-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
06/11/26 17:27:26 YzlmTHts
998 名前：967
2006/11/26(日) 15:28:59 ID:x84UIuM7
>>989
うわっ、テストが本格的。感謝感謝。
> パーティションが別とは、同一ディスク？別ディスク？
バックアップ元がハードウェアRAID1の1パーティーションで、
バックアップ先が別の単体HDD。
CPU: Athlon64
メモリ: 2GB
OS: RHEL 4 x86_64
２台運用していて、両方で発生します。
ただバックアップ先はRAID1してないので、セクタ破損の可能性高いと思います。
9:login:Penguin
06/11/26 17:27:56 YzlmTHts
＞２台運用していて、両方で発生します。
＞ただバックアップ先はRAID1してないので、セクタ破損の可能性高いと思います。
10:967
06/11/26 17:46:31 x84UIuM7
訂正です。
２台のウチ、１台はバックアップ先も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
06/11/26 17:49:51 u2118iB9
ケーブルかHDDか、いずれにしろ普通はハードウェア系と思われますね。
ドライバでバグってるときもたまにこういうエラー出ますが。
12:login:Penguin
06/11/26 18:15:07 N1CLRFC8
>>10
ぐぐってもHDがクラッシュする予兆とかしか出てこないけど...?
シーク失敗->よってリードできない->修正不能エラー->fsもエラー出力じゃないの
13:login:Penguin
06/11/26 18:17:34 N1CLRFC8
あととりあえずpioにしてみてエラーがでないようであればDMA回りかドライバで、
それでも同じようにエラーでるならhddがまずい、んじゃないでしょうか。
14:login:Penguin
06/11/26 18:26:17 sgdsyv/U
fc5かその辺でdmraidかなにかがめちゃ不安定で鳥変えたことがある。
FedoraもRHELも同じようなもんだから、多分その回りが腐ってるのかもね。
15:login:Penguin
06/11/26 18:42:19 XsQxK8M4
HDDのインターフェースがVIAだったりしないよな・・・・・
CPUがAMDだったりしないよな・・・・
16:967
06/11/26 19:06:53 x84UIuM7
>>11-15
なるほど、ハードウェアかドライバ周りでしたか・・・。
通りで似たような構成のサーバで、HDDを取り替えても起きる訳ですね。
> CPUがAMDだったりしないよな・・・・
Athlon64です・・・。
というわけで、あとはスレ違いになるので、
今度サーバ止めれる時にいろいろ実験してみたいと思います。
ありがとうございました。
17: ◆IIiDC8JS7w
06/11/26 20:36:54 UfgRl6db
Σ(ﾟДﾟ)ｶﾞｰﾝ
昨日からのテストはいったい。。。
どうせなんで、11/30 19:00まで流してますよ。
ちなみにディスクは2年前の
ST3400832AS (400GB SATAII 7200rpm)
18:login:Penguin
06/11/26 21:19:41 3iokBptU
>15
>CPUがAMDだったりしないよな・・・・
ずいぶん旧いタイプのIntel工作員だにゃ
19:login:Penguin
06/11/26 22:11:56 x84UIuM7
>>17
そのテスト、それはそれでFSのいい比較になりそうですねー。
それぞれのパフォーマンス比較もあるとさらにいいかと。
20:login:Penguin
06/11/26 22:18:39 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
06/11/27 00:16:05 0mSVab+o
とにかくファイルのアクセス速度を重視したFSってお薦めありますか？
22:login:Penguin
06/11/27 00:38:45 mgDpZR80
tmpfs
23:login:Penguin
06/11/27 01:05:45 cfi4pI48
reiser4
24:login:Penguin
06/11/27 01:06:16 9Y+78YyZ
やはり一理も二理もあったわけだなｗ
25:login:Penguin
06/11/27 03:08:12 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
06/11/27 03:09:16 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
となっている（単位は秒）。最初のデータ列は平均値で、残り８つが
実測値。（続く）
27:login:Penguin
06/11/27 03:10:01 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
06/11/27 03:11:43 ygih2dGe
あと気づいたのが、fsによって処理中のコンテキストスイッチの
入り方が違う。これはxfs/jfsとext3/reiser*グループに分けられて、
前者は後者の10-20倍スイッチングする。
カーネルハッカーな人に教えて欲しいんだけど、これはxfs/jfsでは
処理が細粒度に分割されていて、プリエンプトしやすい、つまり
マルチプロセッサ時のスケーラビリティやリアルタイム処理向きに
なっているという理解で正しい？XFSは元々その領域を得意として
いたので、I/O waitの少なさも生まれが影響しているのかも。
29:login:Penguin
06/11/27 03:13:23 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
06/11/27 03:43:21 gqe6EGX+
>>24
日本語がおかしい
31:login:Penguin
06/11/27 05:10:04 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
06/11/27 05:46:42 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
06/11/27 06:26:35 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の人、一部のデータ出したって書いてあるけど、どのデータ出したんだろう。
最初の行のタイムにしては３倍近く差が付くのは変なような・・・。
34:login:Penguin
06/11/27 11:39:35 zIhTBo3A
俺も似たような状況
Athlon64x2、CentOS4 x86_64、VIA
でmdまわしてたけど
数日後には同じようなエラーが出てどうしても止まる。
HDDもケーブルも変えまくったけど駄目ぽなので
ドライバがくさってるなと結論づけ諦めた。
しばらく32ビットOSでやってたら普通に動いてたけど、
64でやる必要あったので、mdはずしますた。
というわけで32ビットOSでまわすのはどうでしょうか。
35:login:Penguin
06/11/27 12:15:13 V5iOSjFK
前すれ397はext3をdir_indexなしでフォーマット
しているので参考にならない。
36:login:Penguin
06/11/27 14:13:05 NL+5TZr7
（´,_ゝ｀）ﾌﾟｯ
37:login:Penguin
06/11/27 14:23:46 Gl6W36sR
（´ﾟc_,ﾟ｀ ）ﾌﾟｯ
38:login:Penguin
06/11/27 15:06:39 mo7iZrU6
思考実験、ドイツ語ではゲダンケンエクスペリメントはもう終わりましたか？
39:login:Penguin
06/11/27 23:11:33 1WMqFMtM
ext3は高負荷のときに壊れる
xfsにも微妙なところがある
jfsは論外
40:login:Penguin
06/11/28 02:08:45 dIATTNIe
チラシの裏にどうぞ
41:login:Penguin
06/11/28 07:13:42 J+dhV7qO
だからXFSでいいんでしょってのに。
42:login:Penguin
06/11/28 08:15:30 cRzA/Bi/
Linuxのカーネル自体が、高負荷に弱いからなw
43:login:Penguin
06/11/28 08:36:33 mWLPxpmO
ま た 抽 象 論 厨 か
いい加減にしろよハゲ
44:login:Penguin
06/11/28 22:57:31 5TqPHx8Y
ファイルの読み出しを大量に行ったら、全プロセスが 1 分以上動かなくなったことがある。(+д+)
45:login:Penguin
06/11/28 23:03:16 ZKWZRDmg
>>44
おらくSCSI bus reset
46:login:Penguin
06/11/28 23:06:41 +IZBoTgF
いやNFSというオチ
47:login:Penguin
06/11/28 23:07:50 12X1ZwKm
ぬ。
おそらく、ね。
48:login:Penguin
06/11/29 11:46:21 4v2KUCQc
macのドライブにアクセスする方法ありませんか？
49:login:Penguin
06/11/29 12:09:14 IMfnsoFA
samba
50:login:Penguin
06/11/29 20:53:33 lIbQSUXt
>45
そんなことで 1分も時間がかかるのか?
51:login:Penguin
06/11/29 23:42:54 a8L0fs7M
2.6.19-rc6 とかで generic file writeとか
削除されてるだんけど何で？
52:login:Penguin
06/11/30 06:52:55 174bag3/
URLﾘﾝｸ(sfgate.com)
> 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
06/11/30 07:06:37 rKSOEWU+
>>52
なんだ、まだ死体も見つかってないどころか、死んだかどうかの
確認すらできてないんじゃん。
なんか証拠が見つからなくなって面倒くさくなった警察側が
寝技使って落しどころ探してるって感じなんじゃないのか。ひどい。
54:login:Penguin
06/11/30 07:42:45 wl2BA0uA
Andrewの陰謀だ
55:login:Penguin
06/11/30 07:47:16 xHQdO+fK
どの国も警察っていいかげんだなあ。
56:login:Penguin
06/11/30 15:17:18 xxzhfaCv
>>55
何人もが行方不明になっても、何年も放置しておく警察もあります。
57:login:Penguin
06/11/30 15:18:33 8qpZwMYe
>>56
だっている場所分かってるニダ
58:login:Penguin
06/11/30 18:30:13 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
06/11/30 19:36:11 MWVY75+p
aclは全部完全に管理できなきゃ意味ないｗ
不完全ならない方がいい。
60:login:Penguin
06/11/30 20:21:32 mmMkv7Ur
aclとattributeはちがうだろ
61:login:Penguin
06/11/30 21:26:40 3HsodbO8
しーっ
62: ◆IIiDC8JS7w
06/11/30 23:44:34 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
06/11/30 23:56:49 aEiu/0E7
>>62
お疲れさまー。
やはりFSとrsyncだけでは問題は出ないようですね。
カーネルやドライバのバグ、ハードの問題などが原因でしょうか。
64:login:Penguin
06/12/01 02:21:18 hovM2rQ4
OSCON2006でFS比較話があって、内容自体はほとんどこのスレと
同じなんだけど、１つだけ「JFSはIBMに捨てられたのが欠点」という
話があったらしい。これ何のこと？
65:login:Penguin
06/12/01 03:08:08 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
06/12/01 03:22:36 XMuKng2p
結果見直してみるとちょっと速すぎるな・・・
何かベンチのパラメータ落としたかな？？UFSとZFSでもう一度取り直してみる。
67:login:Penguin
06/12/01 03:42:44 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
06/12/01 03:43:15 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
06/12/01 04:13:20 HVWtIxPt
異常な速度だなぁ。ZFSは実際にディスクには書いていないんじゃないの?
70:login:Penguin
06/12/01 10:35:57 mEhJq9GL
>>65-68
なんじゃこりゃー。
化け物だ・・・。
乙です。
71:login:Penguin
06/12/01 11:34:02 y8bRU7K1
>>69
それは某FSに対する
なにかだな
72:login:Penguin
06/12/01 11:45:31 mq6YGmUl
ここはもう奥村（だっけ？）の出番だな
73:login:Penguin
06/12/01 23:09:35 B+5xJghb
project DOUBT!
74:login:Penguin
06/12/01 23:54:36 SU1ozKXb
>>72
俺？それともTexの？
75:login:Penguin
06/12/02 00:08:01 8gMXyV52
fjの教祖様だろ
76:netadesu
06/12/02 00:20:56 h0fdrb+a
>>71
UFSは磁石が弱くてもしっかり記録されるように１０回上書きしてる。
昔のHDDに対応するための仕様。このため最近のHDDだと５回位間違って
削除してもundeleteできる。
77:login:Penguin
06/12/02 00:58:04 t53s4AAE
>>68
参考になるかも。
URLﾘﾝｸ(spam.workaround.ch)
78:login:Penguin
06/12/02 02:38:56 lPnc7z93
>>77
逆っすよ逆。
リンク先だとZFS激遅で、UFSの方が速いじゃない。
Reiser4はもっとバカっぱやだが。
79:login:Penguin
06/12/02 06:20:06 hUvReIbv
> UFSは磁石が弱くてもしっかり記録されるように１０回上書きしてる。
> 昔のHDDに対応するための仕様。このため最近のHDDだと５回位間違って
> 削除してもundeleteできる。
[これはひどい]
80:login:Penguin
06/12/02 08:06:41 XkytH5qu
UFSが異常に遅いだけなんだよな
81:login:Penguin
06/12/02 08:35:44 JnqgzHJZ
ext4関連
URLﾘﾝｸ(www.atmarkit.co.jp)
82:login:Penguin
06/12/02 09:45:37 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
06/12/02 11:04:37 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
06/12/02 20:36:07 bhOq8sLd
dump/restore によるバックアップって、
激しく稼働しているシステムに関しては
整合性が失われるためによくないのでしょうか？
一度システムを停止して、Knoppix のようなもので
CDブートしてバックアップを取るのが理想なのでしょうが、
システムが稼働中にスナップショット的にバックアップを
取るというのは dump では難しいですか？
LVM を使うべきなのでしょうか？
85:login:Penguin
06/12/02 20:55:18 ABKO4Jin
LVM2は稼働中のシステムのスナップショットを取れない。固まる。
86:login:Penguin
06/12/02 22:07:53 eQc2JRBC
>>84 スナップショットをしたところで、タイミングによってはデータ不整合に
陥る。要するに確率の問題。
確実にバックアップ取りたければ、writeが発生しない状況で取るしかない。
マルチユーザならばtelnetやssh、ftp、NFS、Samba、メールサーバ等の
サービスを停止。シングルに落とせば完璧だが、自動スケジューリングが
難しくなる。
もしかすると、copy on writeで64bitのchecksumを持つZFSならば、
write処理中にスナップショット取って不整合になる事は無いのかもしれ
ないけどね。
87:login:Penguin
06/12/02 22:11:39 +5VOoV6t
>>86
CoWとsnapshotのどこに関係が？
88:login:Penguin
06/12/02 22:22:58 eQc2JRBC
ZFSはファイルが確実に書かれた事を保証できるファイルシステム。
書き込み途中にシステムが落ちた場合、そのデータは捨てられる。
copy on writeなので、生きているファイルのデータブロックを壊す心配も無い。
強力なchecksumにより、ファイルの完全性が保証される。
なので、静止点を作らずとも、オンラインでバックアップできるのではない
だろうか？
89:えぬてーてー社員
06/12/02 22:36:15 gCRA9JZT
そこでnilfsですよ
90:login:Penguin
06/12/02 22:38:23 kzjFlxSY
通常の三倍の容量のディスクをお使いください。
91:login:Penguin
06/12/02 22:41:09 bhOq8sLd
>>88 それって、SoftUpdate とは別モノ？
92:login:Penguin
06/12/02 23:15:34 eQc2JRBC
>>91 実現している事はほぼ同じではないでしょうか。ZFSはcopy on writeを
利用して2^64までのスナップショットを実現しているそうです。
checksum 64bitが自分としてはすごく期待しています。ファイルシステムの
不整合問題についてはジャーナリングファイルシステムでもOKですが、ファ
イルが壊れたまんまになっているのではないかと言う不安がついてまわり
ます。
93:login:Penguin
06/12/02 23:18:29 ABKO4Jin
バックアップについては
金はけちるくせに無理難題ばかり言ってくる奴ばかりでうんざりだ。
だから最近はバックアップの事は口にしない事にしてる。
勝手にデータ失って死ねよって感じ。
94:login:Penguin
06/12/02 23:26:50 eQc2JRBC
>>93 俺もそう思う。最近は1TBを超えるシステムも少なくないんで、フルバック
アップをバックアップウィンドウ内で取る事が困難になってきた。
TapeじゃなくてDiskに取れば速いと勘違いしている人も多いし。困ったもんだ。
送り出しの方の性能(read)が問題になっているのに。
95:login:Penguin
06/12/02 23:57:54 eQc2JRBC
SolarisのUFSがext3よりも速いと言っているが本当かな？
URLﾘﾝｸ(www.sun.com)
96:login:Penguin
06/12/03 00:12:21 Dnl0qBMZ
USFloggingはpostmark専用ということでしょう。
97:login:Penguin
06/12/03 00:18:11 yq6uElX+
>>95
portmarkの結果を見るとなくはないと
98:login:Penguin
06/12/03 00:25:11 EZVqzNiE
portmarkで比較なんかされてたっけ
他所のスレ？
99:login:Penguin
06/12/03 00:26:11 18r037ES
>>96 つーか、Solarisでは標準がUFS Logging。
100:login:Penguin
06/12/03 00:29:21 18r037ES
>>98 95のファイルに
101:login:Penguin
06/12/03 00:35:57 7MHSLQFC
vine linuxをインストールした後に、windows上でrawriteを使ってgrubの起動フロッピー作った。
そして、biosでフロッピーディスクドライブを起動順位の１番上にして、再起動したら…windowsが立ち上がってしまう…汗
原因が分かる人いますか？いたら、教えていただきたいのですが…ちなみに、フロッピーディスクドライブはUSB接続なんですが、関係あるのでしょうか？？
102:login:Penguin
06/12/03 02:22:38 8l+uEP+9
スレ違い
つーか機器構成ぐらい書けよヴォケ
103:login:Penguin
06/12/03 02:26:51 Hcdjmvk5
>>101
フロッピー読みに行ってるのか？
ダメならBIOSでUSBを一番優先させてみろ。
104:login:Penguin
06/12/03 16:59:34 rNEial6W
xfs_repairって、1TBのボリュームにつき1GBのメモリが必要ってどっかで見たんですが、
メモリが足りない時はどうなりますか？メモリが足りないといわれるのですか？
今やってる環境では、unable to verify superblockと途中で出てるだけで、
処理が終了しないのですが？
105:104
06/12/03 21:25:04 rNEial6W
すいません、過去スレに必要メモリ量は、ファイル数によるとありましたので
自分の環境では、関係ありませんでした・・・
xfs_repairの問題って、2.6.19では解決済み？
106:login:Penguin
06/12/04 10:42:22 xZfcs1Y7
changelog嫁
107:login:Penguin
06/12/04 10:54:48 dSD3cIjI
>>106
低脳でもできる回答乙
108:login:Penguin
06/12/04 23:49:18 M3KqaF+X
>>99
ウソんｗ
/etc/vfstabのオプションでlogging指定してたらでしょ。
109:login:Penguin
06/12/05 08:10:07 X6W7O/3k
>>108 Solaris 9 9/04以降はデフォルトがUFSロギング。
URLﾘﾝｸ(docs.sun.com)
この事実は意外と知られていないのな。最近も客にloggingオプション書き忘れて
いるぞとクレームつけられた。mountコマンド実行して見てよと。客苦笑い。
110:login:Penguin
06/12/05 09:58:58 iJO6AsHS
postmark以外のベンチでも同様に速ければ、ね。
デフォルトがどうのではないよ。専用というのは。
111:login:Penguin
06/12/05 10:42:06 3m+29pb2
>>109
それ以前のはSolarisと呼ぶ価値もないと？
112:login:Penguin
06/12/05 11:55:33 ZAhaU2Uy
そんないじわる言うなよ。
113:login:Penguin
06/12/05 13:04:58 58SJGa53
すみません、質問させて下さい。
mkreiserfs における -s <journal_size> オプションを
デフォルト値より増加させることにより、ファイルシステムの
初期使用容量が増加しますが、それと引き換えに
ジャーナルシステムの堅牢化やパフォーマンスの
向上等が見込めるのでしょうか。
114:login:Penguin
06/12/05 22:23:41 Uo1+tsKM
ReiserFS って作者どうなったの？
115:login:Penguin
06/12/05 22:50:02 MfwPTzkp
妻殺しの容疑で逮捕され起訴。
しかし死体も殺人の証拠も見つかっていない。
初公判でHansは無罪を主張。
いい弁護士がつけば某OJシンプソンみたいに無罪になるだろうが……
有名弁護士は「金ない奴の弁護はヤラネ」と辞任してしまう。
漏れの予想: 有罪。懲役20年。
116:login:Penguin
06/12/05 23:04:59 1ryvR00Z
>115
陰謀説もありうる
117:login:Penguin
06/12/05 23:10:04 Uo1+tsKM
死体も見つかっていないってどういうこと？
なんで逮捕されたんだろう。
118:login:Penguin
06/12/05 23:17:39 rXB4Zs2I
Hans Reiser基金があれば寄付したいなぁ。
裁判費用に宛ててもらって、無罪なら余りは全部あげる。
有罪なら余りは恵まれない北朝鮮の子供達へ。
119:login:Penguin
06/12/05 23:21:15 Hfdv8p8G
>>118
> 余りは恵まれない北朝鮮の子供達へ。
それは間違いなく子供たちに届かず核開発に流用されるだろう。
120:login:Penguin
06/12/05 23:31:29 rXB4Zs2I
じゃあ、直接将軍様にでいいや。
121:名無しさん＠お腹いっぱい。
06/12/06 00:08:21 yI66B+zP
>>92
>不整合問題についてはジャーナリングファイルシステムでもOKですが、ファ
>イルが壊れたまんまになっているのではないかと言う不安がついてまわり
>ます。
つーか、ファイルシステムレベルのジャーナリングではデータ部分の整合性は
保証できないだろ。アプリが自分でやらないと。
122:login:Penguin
06/12/06 01:06:36 BnlsXkP+
>>120
氏ね
123:login:Penguin
06/12/06 01:42:02 DBbsU8xP
>>122
<＃｀Д´> 癇癪起こる！
124:login:Penguin
06/12/06 08:30:11 6a3HiqpI
>>121 そこでZFSですよ。256ビットのハッシュデータ。
125:login:Penguin
06/12/06 10:12:00 tCUoJ222
>>124 それはちゃんとファイルが書き込めた後での
長期的な同一性保証のためのものじゃないかな。
126:login:Penguin
06/12/06 14:00:30 ifaylv2S
HDDにデーター領域を作ったので興味本意でxfsにしてみました。ネットで結構優秀とか大きなサイズの
ファイルには良いって書いてあったのですが。。。書き込みがやたら遅いんです、1Gのファイルのコピー
をしてみたのですがext3からext3で28秒、ext3からxfsだと2分近い。読み込みは計ってませんが体感
的にはext3より早そうです。。。しかし大きなファイルの書き込みが特に遅いです('ヘ`;
これって何かの数値をチューニングしなければいけないのでしょうか?それとも自分のOSかハードがおかしい
のかな。。。ubuntu6.10-i386なんですが。
127:login:Penguin
06/12/06 14:08:11 VuLfvWGj
>>126
ハードウェア情報書いて無いから、
エスパーでもないと回答不可能。
128:login:Penguin
06/12/06 14:57:47 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
06/12/06 15:03:30 pwSD0KnX
PIOモードになってたというオチ
130:login:Penguin
06/12/06 15:28:52 pSdv9N8K
write back cacheまわりとか?
131:login:Penguin
06/12/06 15:37:04 ifaylv2S
>>129
一瞬もしやと思ったのですがhdparmで調べるとDMAはオンです。 -t オプションで速度も計ってみました。
hdaが 45.35 MB/secでsdbは 53.92 MB/secでした。
やはり書き込みが遅いですね。読み込みの倍なんてもんではなく3倍から4倍くらいの時間がかかってます(TT)
132:login:Penguin
06/12/06 15:44:48 ifaylv2S
>>129-130 いろいろな御意見ありがとうございます＾＾
write back cache? ちょっとググってみます＾＾；
後気になった点は先程書き込みをしている状態でhdaからsdcへファイルをコピーしてみました。
これで読み書きフル稼働状態なのですがCPU稼働率が70から80へとポンポン跳ね上がります。
ファイルの読み書きだけでこれはあがり過ぎですよね?
133:login:Penguin
06/12/06 16:03:54 ifaylv2S
うわああああああ(><)
今起動しているのが2chブラウザーのv2cとシステムモニターだけ。。。
実メモリー使用が378Mって。。。なんかディスクの読み書きで使用したメモリの開放がされてない
っぽい。しかもシステムモニタで目に見えるメモリーの合計はそんないってないです。
仮想メモリーも表示にしたらjava 692M(おいおい、これ勘違いではw)それとnautilus 362M
くさい。。javaはv2cなので一度v2cをとじます。案の定メモリーは減りません。
ファイルの読み書き時もCPUパワー食っていたのがnautilusでした。これってwindosでいう
exdplorer、ようはファイルマネージャーですよね?
134:login:Penguin
06/12/06 16:20:57 ifaylv2S
ext3へ変更します。今実験したらnautilusのメモリとも違いますね。システムモニターに写らない何かが
メモリーを開放してくれません(一度でもxfsへ書き込んでしまうと)
135:login:Penguin
06/12/06 16:26:44 q9ltKIye
それDelayed Allocation
136:login:Penguin
06/12/06 17:14:30 TcRO1p0L
これは本家と無関係なんでつか？
URLﾘﾝｸ(www.xfs.org)
こんなドメインよくとれたな
137:login:Penguin
06/12/06 17:15:59 wIp7BUbr
>>133
ファイルシステムやVMの基本、Linuxにおける実装の特性
について勉強し直したほうが良いのでは？
URLﾘﾝｸ(www.atmarkit.co.jp)
138:login:Penguin
06/12/06 20:13:24 6a3HiqpI
ZFSのsnapshotって一瞬で終わりますね。rollebackも10秒とかからない。
2000個近いファイル、計1GB位を書き込んでrollebackしてみたのですがすぐでした
使ってみるとNetAppのDataONTAPと本当に機能が似ています。
snapshotから過去のファイルを読み出すときも、
# cp /pool/home/user/.zfs/snapshot/snap1/file . みたいな感じですから。
139:login:Penguin
06/12/07 02:36:17 TfaVgQxt
raid-z x2で片方をSVN+WevDavサーバにしたい。
そんな権力俺には無いけどね
140:login:Penguin
06/12/07 07:40:01 AQ8VWnTG
WebDAVで各ユーザのhome directoryを見せたいんだけど、認証とACLが今ひとつ
分からない。Sambaみたいに自分のhome以外はアクセスさせない設定をしたいの
ですが。
141:login:Penguin
06/12/07 10:04:48 KfNP6Zhh
WebDAV使うからわからなくなるんだ
142:134
06/12/07 20:03:50 T+r6TgE/
>>137
ファイルシステムも奥が深そうですね。当り前ですがかなり中で働いているのですね＾＾；
記事は参考として読んでみました。
ググってみたら私と同じような症状の方がいました。ubuntu+GONOMEのnautilusにて発生するようですが
あまり騒いでいる様子が無いところをみると出る人とそうでない人がいるのかな。もしくはxfsを使用して
サーバーとか建てる方はubuntu+GNOMEって人が少ないのかな。
データーディスクをReiserFSにしてみたらなんと調子がいいのです。ext3からext3へコピーをしたりする
よりも早い上何故かCPUパワーとメモリーを食いません＾＾；
>>133とまったく同じ処理をさせてメモリ使用170Mで書き込み時間は1/7ほどになりました。当分これで
いってみます。
143:login:Penguin
06/12/08 10:31:53 ta6ZGDEB
>>142
おまえは何にもわかってない。
そのページのコラムをよく読め。
ディスクキャッシュでメモリが使われる分には無害。
「メモリを余らせるのはもったいないからディスクキャッシュとしてどんどん使え」
というのがLinuxの基本的な実装方針。
144:login:Penguin
06/12/08 15:58:51 JLsqtU7n
でもCPUが全然違うみたいじゃん
145:login:Penguin
06/12/09 03:28:56 EBN5bRDP
ZFSみたいなファイルシステムが普通になってくれば、LVMなんていらなくね？
146:login:Penguin
06/12/09 05:50:59 MBLL7Uyo
>>143
開発とかしてる訳でもないし、趣味なんで別にそこまで詳しくなろうとも思わんわ
噂でいいって聞いたxfsを使ってみようかなくらいの感覚だったしね。しかしext3が10分で書き込みが終わるの
に70分掛かってるしメモリも馬鹿喰いで。。ｲﾗﾈ
結局ext3をメタデーターと完全データーの両方をジャーナルするモードにして使用することにしました。
ReiserFSは軽くて早いしよかったけど今後の事を考えるとスムーズに次世代のext4へ移行できる環境
がいいかなと。xfsは相性が悪かったので残念です。
147:login:Penguin
06/12/09 10:06:19 XepFnD8l
>>146
なんでそんなに自分自身のバカさ加減を他人に喧伝したいの?
148:login:Penguin
06/12/09 10:41:34 XvZbgYpg
>>146
素直にreiserfs使っておいて、スムーズにreiser4に移行しろよって話だわな。むしろその前にzfsが普及する可能性があるが。
149:login:Penguin
06/12/09 11:01:59 PRqPU+Ss
Linuxにzfsの移植なんてまともに出来るんか？フルスクラッチで。
150:login:Penguin
06/12/09 11:13:49 XvZbgYpg
詳細にドキュメント化すれば何とかなるでしょ
151:login:Penguin
06/12/09 11:26:27 OrMFCIvy
SunがGPL化する方がはやいんじゃないの？
152:login:Penguin
06/12/09 12:18:02 MBLL7Uyo
>>148
確かにその選択をしようかと思ったのですが結局もっとも無難な方向でしまいました＾＾；
153:login:Penguin
06/12/09 13:13:51 oECGYLlp
それより Sun が ZFS のラインセンスを移植可能なモノにするかなぁ。
あと、ReiserFS ってこれからも続いていくのかなぁ。
と弱気なオレは ext3 でいいや、ってことにしてる。
154:login:Penguin
06/12/09 13:20:37 XvZbgYpg
>>153
サン、「OpenSolaris」へのGPL適用も検討中--幹部の発言で明らかに
URLﾘﾝｸ(japan.cnet.com)
可能性は無くは無さそう。
#ってかSecond Lifeって…
155:login:Penguin
06/12/09 13:49:40 a073A2ss
CDDLなんて最初からうまくいくわけないって散々言われてたのにな
156:login:Penguin
06/12/09 14:42:03 +BMSQsJ6
>>134
いまいちよくわからんのだが俺も nautilus + XFS で信じられない位遅かったな
コピーしようとしたら CPU 占有 & 超低速で笑った。迷うことなく速攻 kill
でも普通に cp したら早かったんで FS じゃなくて GNOMEが悪いんじゃね？
日本語ファイル名ばっかりだったからシェルでいじるのダルかった...
157:login:Penguin
06/12/09 15:01:16 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
06/12/09 16:35:25 6c2eJaxy
>>126->>132 のファイルコピーってnautilus使っての作業なのか？
普通にcpでの作業を想定したぞ。
>>133で初めてnautilusで出てくるんだが、
cpだと普通の速度で、nautilus使ったら激遅ならnautilusのせいで
fsのせいではないだろ。
159:login:Penguin
06/12/09 17:08:13 rWrLJc8b
NautilusはGnomeの癌
今までも、そしてこれからも
160:login:Penguin
06/12/09 17:55:39 M+her1pQ
gnomevfsはデザイン上の問題があってデータが壊れることがあった
URLﾘﾝｸ(blogs.gnome.org)
gnomevfsは問題多すぎでうんこでファックなので新しいのに変えようぜ
URLﾘﾝｸ(mail.gnome.org)
gnome,nautilus自体つかってないのでなんとも。
161:login:Penguin
06/12/09 19:19:33 5nAPCmxh
nautilus2.16+reiser3.6では遅くならんな
162:login:Penguin
06/12/09 20:52:16 xcZ61voz
結論はnautilus+xfsがダメってことでOK？
163:login:Penguin
06/12/09 21:01:20 PRqPU+Ss
結論はnautilusがダメってことでOK
164:login:Penguin
06/12/09 21:15:29 QVIoEzpT
ダメなのはお前らの脳だと思うんだがなぁ
165:login:Penguin
06/12/09 21:18:23 OsYlNHdM
なんだかんだでXFS重いネタは発展したじゃん。
nautilus + xfs で遅くなることを報告し問題を探ろうとした質問者に拍手。
166:login:Penguin
06/12/09 21:31:31 QVIoEzpT
( ﾟдﾟ) ・・・
(つд⊂)ｺﾞｼｺﾞｼ
_, ._
（；ﾟ Дﾟ） … 何ひとつ発展してないように見えるが！？
167:login:Penguin
06/12/09 21:51:29 6srhV/6+
自分で原因も追求できないようなやつは
素直にext3でも使ってろってこった。
168:login:Penguin
06/12/09 22:11:49 1d5W5tst
2.6.17.7から2.6.18.3, 2.6.19に変えたらXFSの大量ファイル削除やコピーが
重くなった気がする。
SATAドライバのせいかもしらんけど。
169:login:Penguin
06/12/09 22:14:16 QVIoEzpT
気にするな。
170:nautilusの人
06/12/09 23:08:49 MBLL7Uyo
おお！ なんか原因らしき物が見えてきましたね。みなさんありがとう。
ちなみに今Reiser4をカーネルに組み込んでコンパイル中です。
メモリとかの設定などもついでに変えてみました。make configの中を見ると確かにLinuxは標準で
ntfsを持っているんですね。デフォルトでMになってないのはWINに対する嫌がらせかと思ってしまったりw
あとはこのカーネルがまともに立ち上がるかです。。。
171:login:Penguin
06/12/10 00:35:07 IFH3c9Be
>ntfsを持っているんですね。デフォルトでMになってないのはWINに対する嫌がらせかと思ってしまったりw
バカなのかなぁ・・・
172:login:Penguin
06/12/10 00:54:36 CiyFfnIL
>バカなのかなぁ・・・
多分，若くていろいろと経験が足りないだけだと思う。
173:nautilusの人
06/12/10 01:13:22 TgXM1Sad
ここの住民はじじいばっかかwwwww
174:login:Penguin
06/12/10 01:15:16 ZIVzZTYQ
カーネルこねてるんなら、カーネルのNTFSサポートのHelp読めよ
175:login:Penguin
06/12/10 02:52:33 0gb/zk4T
開発もしてないのに趣味でカーネルビルドしたり
ファイルシステム変えたり
奇特な若い衆ですね。
176:login:Penguin
06/12/10 03:10:45 /uFKb+GK
>>170
もう二度と湧いてくるな
177:nautilusの人
06/12/10 03:46:13 TgXM1Sad
>>171 >>174
しょせん俺は何も知らない馬鹿だよ。でもおまえらの人を見下げたような文章もあまり知性が感じられないぞ
アホタレどもめ
>>176
おまえに言われなくても二度とこねえよw このお子さまランチめ
最後に一言
このスレで色々と情報をくれた方々に、ありがとうございました
178:login:Penguin
06/12/10 03:50:27 88+w2rhZ
>>175
んー？それに関しては別に問題ないんじゃない？
学生さんでインストールマニアだったらカーネルビルドとか
気に食わないfs捨てたいから変えるくらいするだろ。
むしろ最近の学生はそれすらできない香具師しか多そうだし、
良い方の奇特な香具師だと思うぞ。
179:login:Penguin
06/12/10 09:34:16 jHWNrXu/
そうだそうだ、オプション変えてカーネルのビルドを繰り返すうちに
カーネルの内部構造に興味をもっていくもんなんだ。
てなわけで、ガンガレ>>177
180:login:Penguin
06/12/10 10:08:51 CiyFfnIL
まぁ，がんばって欲しいところではあるね。
ただ，他の人が理解の仕方がおかしいと指摘していることに関しては，
もう少し努力する必要があると思うけれど。
181:login:Penguin
06/12/10 12:06:52 WasA3VVH
残り少ない今年の目標
若い奴は生温かく谷底に突き落とせ!
182:login:Penguin
06/12/10 13:19:59 XLohVbNm
>>180
努力はしてほしいけどな。
ただ、>>177みたいにキレて捨て台詞吐いて逃げるってのはやめた方がいいな。
183:login:Penguin
06/12/10 14:29:45 jHWNrXu/
>>182
今頃の若者にしては、捨て台詞の後に礼をしているあたりが
見所がある。
184:login:Penguin
06/12/10 16:35:52 2HNgBmx6
どう見ても精子です。
本当にありがとうございました。
185:login:Penguin
06/12/10 17:20:16 sXlQ0bnD
知らないこと・わからないことを公の場で聞けるのは立派
それを見下す連中こそ馬鹿 おまえ達だって知らない時期があったでしょ
わざわざ暴言書く暇があるならどっか参考になるURLでも示す方が生産的。
でもどんな理由があってもキレ台詞はやめたほうがいい。品性が落ちる。
186:login:Penguin
06/12/10 17:49:38 TNoYmltu
少なくとも匿名掲示板で何か教えてもらったというのは記憶に無いな。
187:login:Penguin
06/12/10 17:56:35 hIevwezh
ググればわかる情報は教えてもらえないだろう
質問されたほうはムカつくもんな
188:login:Penguin
06/12/10 20:51:36 /uFKb+GK
>>185
教えてクンを肯定するのもなぁ。
189:login:Penguin
06/12/10 21:03:49 b8muUvr3
>>185
罵倒することも立派な教育だよ。 無視するよりはずっと良い。
190:login:Penguin
06/12/10 21:26:54 aQAOhBxb
馬鹿ばっか。
191:login:Penguin
06/12/10 21:27:47 AaJ/gQWg
と馬鹿が申しております。
192:login:Penguin
06/12/11 02:11:53 WQUWzS9F
>>185
>わざわざ暴言書く暇があるならどっか参考になるURLでも示す方が生産的
ということで
っ URLﾘﾝｸ(www.linux.or.jp)
いやこっち(も)だな w
っ URLﾘﾝｸ(www.linux.or.jp)
>>178
>むしろ最近の学生はそれすらできない香具師しか多そうだし
今は学生に限らず社会人までそうだもんな。「そんな事聞いて無いからしませんでした」ってばっかり・・・
まあとにかくガンガレ
193:login:Penguin
06/12/13 00:48:25 bqgQBo7n
Solaris10 11/06出た。RAID-Z2(RAID6)とホットスペア機能が使えるようになった。
194:login:Penguin
06/12/13 18:51:41 b8bVQzXm
はやく移植されないかなー
195:login:Penguin
06/12/14 19:38:33 DclqJgck
ext2fsdってどうですか？安定してますか？
196:login:Penguin
06/12/15 07:46:57 YAtgT/AF
うん。
197:login:Penguin
06/12/16 06:30:03 KNwmu5Y4
サイズの大きなパーティションにファイルシステムのイメージごと dd などでコピーして
その後ファイルシステム自体も成長させられるようなファイルシステムってありますか？
縮小はさらに難しそうだなぁ
198:login:Penguin
06/12/16 07:19:02 KNwmu5Y4
うぉ、mdadm で linear なアレイ作って
後でいくつかディスク追加しようと思ったら
--grow は linear では使えないって orz
199:login:Penguin
06/12/16 07:32:43 +S1DoSTm
loopbackデバイスを使ってLVMとかできるんじゃねえ？
やったことないし縮小も無理だけど。
200:login:Penguin
06/12/16 08:56:25 h5sW2mHZ
linearってなんだっけ？
コンカチネイト（JBOD）だっけ？
それともストライプ（RAID0）？
201:login:Penguin
06/12/16 09:49:45 ozfgfRrw
>197
そこまで具体的に言われたら FreeBSD の ufs だって出来る...
Linux の FS も含めてどれだけ実用的・安全に出来るかどうかは
たぶん全然別の問題という気がするけど
202:login:Penguin
06/12/16 10:15:07 +S1DoSTm
>>197
スマソ
ddでイメージファイル作って、イメージファイル内のファイルシステムを成長させる話と勘違いしてた。
GNU Partedを使う場合
URLﾘﾝｸ(nobumasa-web.hp.infoseek.co.jp)
ファイルシステム付属のユーティリティを使う場合
URLﾘﾝｸ(pantora.net)
FreeBSD のufsもgrowfsがある
203:login:Penguin
06/12/16 11:48:37 KNwmu5Y4
>>200
madam --cretae --level linear は JBOD っす。
余った小さなディスク（60GB）くらいのがちょこちょこ
集まってくるんで、くっつけて作業用にでも使おうと思って。
>>201-202
ufs ってのは成長させられるんですね。
いままで ext2 ext3 くらいしか使ったこと無かったんで
今から手探りでいろいろ試してみようかと思ってます。
OS は Linux 。何かあってもいいように VMware 上の
Debian か Fedora Core で実験予定。
204:netadesu
06/12/16 15:05:21 SIzSeUHT
growだったらできないfsの方が稀じゃないか？
ただ、hot expandできるかどうかは別。
やらないにこしたことないから常用してはないけど、
ext2(3だったかも), reiserfs, xfs ではやったことある。
205:202
06/12/16 17:18:02 +S1DoSTm
GNU Partedも現在はufsのリサイズサポートしてるみたい。
URLﾘﾝｸ(www.gnu.org)
growfsのラッパーだろうけど。
206:login:Penguin
06/12/16 17:23:46 XtbPeLaZ
ext2/3はpartedよりresize2fsの方が確実
parted、拡張に追いついてきてないし
そして名前も出てこないjfs(-o remount,resize)かわいそす
207:login:Penguin
06/12/16 17:26:19 FC6GU6Ut
みんなぶっちゃけ、jfsなんて使ってないんだろ？
208:202
06/12/16 18:18:47 +S1DoSTm
>>206
> そして名前も出てこないjfs(-o remount,resize)かわいそす
> ファイルシステム付属のユーティリティを使う場合
> URLﾘﾝｸ(pantora.net)
ちゃんとでてるだろｗ
209:netadesu
06/12/16 19:52:23 SIzSeUHT
>>207
トップ３以外はあまり使ってもらえないのが実情だから。
reiser*の開発がBSD訴訟された*BSDみたいに遅延しそうな気配があるから
数年後にはext4,xfs,jfsの３強になってるかもね。zfsも期待。
210:login:Penguin
06/12/16 20:05:37 82ULKkhv
>>209
またまた冗談を(AA略
zfs,reizer*,ext*の3強に決まってる。
211:login:Penguin
06/12/16 20:13:37 b3Zossa2
zfs(raidz,2)のハード実装ってどれくらいで出てくると思う？
誰かが作ってると思うんだ。
どういう感じのデバイスに見えるのか分からんけど・・・・
212:login:Penguin
06/12/16 20:23:39 FC6GU6Ut
CDDLで成功したソフトウェアってないんじゃないの。
オープンソースなのはありがたいけど、CDDL読んだあとにパッチを
コミットしようと考えるボランティアはあんまりいないんじゃない。
jfsはGPLなのにボランティア少なそうだけど。
213:login:Penguin
06/12/16 20:53:55 rOPtoKv8
>>212
なので、OpenSolarisのGPL化なんて噂はある。JavaもGPL化って噂だし。
214:netadesu
06/12/16 21:44:56 SIzSeUHT
>>213
旦那旦那、噂じゃないですよ。それは去年の話。
215:login:Penguin
06/12/16 21:52:53 KoFH3LYy
キリンさんのOS
Nexenta OS
URLﾘﾝｸ(www.gnusolaris.org)
216:login:Penguin
06/12/16 21:59:32 qYQjoEYU
>>215
銀河麒麟をもちだしてきたのかと思った。
217:login:Penguin
06/12/17 00:23:09 Q2xF4z7Q
URLﾘﾝｸ(www.drk7.jp)
> 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
06/12/17 02:01:49 iXfl1BVU
キチガイの書いた文章を読むとキチガイが伝染るよ！
うんこに触ると手にうんこ付くよ！
ﾊ_ﾊ
('(ﾟ∀ﾟ∩ つくよ！
ヽ 〈
ヽヽ_)
219:login:Penguin
06/12/17 02:26:58 Q2xF4z7Q
> Server File Cache → Storage の解説によれば、
URLﾘﾝｸ(www.dd.iij4u.or.jp)
ここの事なんだけど、何のことだかさっぱりわかりませんです。
220:login:Penguin
06/12/17 02:29:31 iXfl1BVU
ウンコ臭いリンク貼るのやめてください。
それとも本人ですか？
221:login:Penguin
06/12/17 02:31:55 Q2xF4z7Q
本人が、「何のことだかさっぱりわかりませんです。」とか言いますか？
で、２つのリンクともキチガイが書いたと？
222:login:Penguin
06/12/17 02:34:53 iXfl1BVU
yes
yes
223:login:Penguin
06/12/17 02:37:30 Q2xF4z7Q
そうですか。
少し興味を持ったので貼ってみたんですが、騙された私がアホだということでしょう。
224:login:Penguin
06/12/17 05:16:30 RV23LfOh
散々既出のネタだから過去ログでも漁ってこい
225:223
06/12/17 07:18:22 Q2xF4z7Q
>>224
過去ログ一応その2から読んだ。（丁寧に読んだのはその２だけ）
ついでに、「何のことだかさっぱりわかりませんです。」と思ったリンク先も読み直した。
まあ、確かにうんざりするくらい語られてるねえ。
後、奥山氏がいわくつきの人物なのもわかった。
で、結局ジャーナルファイルのsyncは保証されてるのかどうかはよくわからなかった。
ジャーナルファイルがvfsレイヤを使わず、独自ルーチンを使ってるって反論もあったけど、
独自ルーチンがsyncを保証してる説明はなかったよ。
Linuxは当初から性能重視で非同期書き込み、*BSDは信頼性重視で同期書き込みを志向してたはず。
どちらが正しくても、正直構わないけどここの住民はもうちっと骨のある反論しろよ。
226:login:Penguin
06/12/17 11:15:48 OfbsfsR3
>225
つ URLﾘﾝｸ(www.drive.ne.jp)
その内容を読み取ってなにが正しいか判断するのはお任せする。
227:login:Penguin
06/12/17 11:25:23 hhbkxu9f
また奥なんとかかよ
飽きねえ奴だな
228:login:Penguin
06/12/17 12:46:25 23TZod3p
ID:iXfl1BVUのように発狂しているだけの包茎くん。
HIVに感染しやすくなるんだから、とっとと手術しろよ。しかも臭いし。
お前、生きる公害だぞ。
229:login:Penguin
06/12/17 13:50:10 iXfl1BVU
>>228
本人キター！
230:login:Penguin
06/12/17 14:50:56 edSVj54I
ID:iXfl1BVU はちょっと黙っててくれないかなあ。
231:login:Penguin
06/12/17 15:33:19 iXfl1BVU
じゃ黙ってるから存分に有意義な議論をしてくれ
232:login:Penguin
06/12/17 15:51:41 gBsLzMH4
つか奥屋マンコのスレでも立ててそっちでやれってかんじー
233:login:Penguin
06/12/17 15:58:34 PCiXBd2b
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――‐┬┘
|
＿＿＿＿.＿＿＿＿ |
| | | |
| | ∧＿∧ | |
| |（ ´∀｀）つ ミ |
| |/ ⊃ ﾉ | |
￣￣￣￣'￣￣￣￣ |
| ext3
234:login:Penguin
06/12/17 17:54:13 Q2xF4z7Q
>>226
メーリングリスト一応全部読んだ。
議論の余地がないでしょ。
LinuxのsyncはHDDのバッファをフラッシュしない。
235:login:Penguin
06/12/17 18:51:54 eRUWixex
そして、FreeBSDでも6以降はフラッシュしない…
236:login:Penguin
06/12/17 19:22:58 6nMM/n3x
次の展開はわかっている！
こうだ！
NetBSDマンセー (35歳 会社員)
237:netadesu
06/12/17 19:29:46 Df4Nxwhq
BSD vs Linux って考えてみれば UNIX の最下層でどちらが下か
やってるだけなんだよな。
Solaris/AIX/HP-UX/SUPER-UX... とかの世界のファイルシステムってどうなんだろう。
238:login:Penguin
06/12/17 20:22:16 7CL4+VjT
NetBSD + LFS最強説
239:login:Penguin
06/12/17 21:16:34 xnDjwphy
いずれにせよLinuxのソフトウェアRAIDでは
grow ができないので、あんまりメリットか無い気がする。
LVM を使ったことが無いので外しているかもしれない。
240:login:Penguin
06/12/17 23:38:46 BpKCD3FA
>>239
dm,mdは適宜使い分けるべし。どっちを上にも出来るから。
241:netadesu
06/12/17 23:39:16 Df4Nxwhq
growさせるつもりならLVM-on-RAIDにして、ディスクを追加するときは
独立したRAID-1/5セットをPVとしてLVMに追加してgrowさせるよ。
見せ方は違っても、これは他のOSでも同じじゃないの？
物理デバイス冗長を取る部分と可変長な論理デバイスを実現する部分は
直行してるはず。
242:login:Penguin
06/12/18 01:53:56 5CjTidJ8
めちゃくちゃパフォーマンス悪そうだがｗ
243:login:Penguin
06/12/18 02:05:56 Nty7XqwY
俺もLVMにしてる。
244:login:Penguin
06/12/18 02:24:08 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
06/12/18 03:11:56 F98nsRY8
>>241
あれ？俺いつのまに書いたっけ？
246:login:Penguin
06/12/18 05:49:01 lBfvMR/v
ふむ、md でも JBOD できるけど、grow する事を考えれば
LVM 使えってことですか？そもそもソフトウェアRAIDの枠組みの中で
JBOD できる Linux が変態？
247:login:Penguin
06/12/18 07:27:40 oHr+ULas
頭悪そうだね
248:login:Penguin
06/12/18 08:14:37 sqlaZvsB
本家HP-UXのように、md（ソフトウェアRAID）とLVMって調和が取れてないから、
組み合わせて使うのはためらうんだよな。
ZFSはソフトウェアRAID、LVM、ファイルシステムのLinuxが弱い部分を一気通貫でカバーしてるからな。
249:login:Penguin
06/12/18 08:34:26 etiTNDak
>>248
なんで前半は HP-UX なのに、後半は ZFS?
ZFS みたいに一体化したものは置いとくとして、
Linux の LVM 自体は良くできてると思うけどなあ。数十台、数十TB
使ってるけど、構成情報のバックアップだけ残しておけば、そうトラブル
復旧も難しいわけじゃない。
250:login:Penguin
06/12/18 15:13:18 8QMqXAUL
LVMについで一文
ZFSについてでもう一文
251:login:Penguin
06/12/18 18:30:49 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
06/12/18 18:31:51 pj2+GtGf
>>251
Windows は板違い。
PC初心者
URLﾘﾝｸ(pc7.2ch.net)
253:251
06/12/18 18:31:58 Y/ed09i4
すいません
誤爆しました
254:login:Penguin
06/12/18 22:50:45 7eT6c4q7
ちょいと、お聞きしますよ。
自宅のメールサーバをPPCにしようかと思ってるんですよ。
で、ファイルシステムの実績を見てたんですがイマイチ分からない。
エンディアンが違ったときの使用実績がわからんのです。
SGI、IBMが作ったxfs、jfsはそのあたり何とかなってそうですがどんなもんでしょう。
非intelアーキテクチャで動かしてる人もみんな大体ext3なんですかね？
ま、壊れても困るのは家族くらいなんでドレでもいいという話はありますが。
興味ひかれてということで。
255:login:Penguin
06/12/19 09:53:23 8O8QeZf3
>>254
ユーザが多いのにしておくのが無難ね？
玄箱すれで聞いてみるとか。
256:login:Penguin
06/12/19 10:43:37 LR+FoNiH
実際のところ、エンディアンは関係あるのかなあ？
俺はないと思うが。
エンディアンで変わるのはファイルの中身だけじゃねえ？
257:login:Penguin
06/12/19 10:52:00 XzW6MizV
file attribute の意味が変わったり
ファイルの大きさが 1600万倍になったりしてもビックリしないの?
258:login:Penguin
06/12/19 10:58:10 8O8QeZf3
異なるエンディアン間でディスクを移動したりすると
やばい聞いた。特にextXとか、mdのメタデータとか。
259:login:Penguin
06/12/19 12:12:40 JTMTN/tV
>>257
それはVFSレイヤの話でないの？
ファイルシステムに直接依存するのだろうか。
260:login:Penguin
06/12/19 12:23:30 JTMTN/tV
それは、ビッグエンディアン環境⇔リトルエンディアン環境を移動させればまずいよなあ。
まさに>257の言う事が起こる。
しかし、そうでない場合に>257が言うようなことが起きればVFSの問題と思うんだが。
261:login:Penguin
06/12/19 12:28:02 JTMTN/tV
とここまで書いておいて気がついた。
何も考えずに書き込み、何も考えずに読み出しても同一環境では問題オコラネー。
VFSもファイルシステムも関係ネー。
違うか？
262:login:Penguin
06/12/19 13:04:19 TnIoz1+9
>>258
んなことねえよ
ちゃんと考えて設計されてるよ
角度とか
263:login:Penguin
06/12/19 13:23:33 8O8QeZf3
>>262
URLﾘﾝｸ(www.ussg.iu.edu)
うひひ
264:login:Penguin
06/12/19 13:31:26 qiS7ynEf
何このレベル低下っぷり？
以前はキチガイも多いがここまで低レベルじゃなかっただろこのスレ。
265:login:Penguin
06/12/19 13:57:36 1t2/+nmt
ext3はOKだと言われているが、他は知らん。
SolarisだとUFSはバイトオーダ依存で、ZFSはバイトオーダ非依存。
266:login:Penguin
06/12/19 14:21:29 skFd6jjj
ext2をi386と～ebな環境で使いまわしてるけど、
いまのところ問題は起きてないな。
ただe2fsprogsは全部試していないので、そのへんに
地雷が埋まってるかもしれん。
267:login:Penguin
06/12/19 14:30:12 O6QzCkRT
>>264
ツマンネ
268:login:Penguin
06/12/19 14:51:31 LBOK3XqF
>>265
今月のSDにZFSの記事があって、
ZFSは書き込みはマシンバイトオーダ、
読み込み時に変換してると書いてあったな。
269:login:Penguin
06/12/19 15:52:09 wh6OROKj
>>268
ってことは、ファイルシステムにバイトオーダが記録されてるのかな？
別のマシンにディスク持って行っても使えるけど
バイトオーダが違うマシンに持って行くと動くんだけどパフォーマンスが落ちる、と。
おもしろいかも
>>255
すまね。
ひねくれてるのでext3とjfsで作ってみた。
jfsがどれくらい頑丈か、かな・・・・
取りあえずディスクを直接持って行っての物理的な共有はしないようにします
環境できたらpostmarkでもやってみるよ
270:login:Penguin
06/12/19 16:34:14 LBOK3XqF
>>269
全くの推測だけどどっかのビットで判別してるんじゃないかな。
0だとLEとか。
記事ではsparcマシンのHDDをintelマシンに持っていっても読める
と書いてあったが、パフォーマンスに関しては書いてあったか忘れた。
変換のオーバヘッドはほんの少しだろうけどあるだろうな。
271:login:Penguin
06/12/19 16:42:59 I6Be52hp
>>269
このスレで大人気の奥山氏曰く
「ついでに言うと、JFSの信頼性のなさも問題があるので、それに修正を当て
ても、『XFSに追いつく』程度でしかない」とのこと。
あくまでもLinuxとFreeBSDとのsync時の挙動の違いについての話の中で
余談としてでてきた話題でソースがないのであれだけど、このスレでも
XFSに比べてJFSって特に信頼性高いとも思えないしメリットないなぁという
のは何度も出てきているね。
272:login:Penguin
06/12/19 16:45:46 DJKXWzFE
チキンな俺は常にext3
273:login:Penguin
06/12/19 16:48:06 WLeCaQbI
いまんとこlinux用はext3中心に回ってるんでおk
274:login:Penguin
06/12/19 17:25:19 JTMTN/tV
普通にupdatedbとかたたくと、ext3遅すぎねえ？
ReiserFSの何倍もかかる。
アクセス時のシーク音は明らかに違う。
275:login:Penguin
06/12/19 17:39:09 DJKXWzFE
ReiserFSは作者の動向が怪しい
276:login:Penguin
06/12/19 17:44:01 qiS7ynEf
怪しいのは作者が住んでる町の警察の動向だろう
277:login:Penguin
06/12/19 17:44:48 5KfKfe1m
あれからどうなった
278:login:Penguin
06/12/19 17:44:55 JTMTN/tV
確かにナorz
将来乗り換えが必要になる可能性大
279:login:Penguin
06/12/19 18:07:21 JTMTN/tV
ext3って皆が使ってるから何か起こっても豊富な情報がある。
それにツール類もまずはext3を前提に作られてると思う。
使うのに十分な値打ちがあると思う。
でも、ツマラネーんだよな。
ext3使っててこのスレ読んでても楽しみ少なくない？
280:login:Penguin
06/12/19 18:10:57 TnIoz1+9
楽しみより安定性
281:login:Penguin
06/12/19 18:17:58 JTMTN/tV
まあ無難な選択を否定することは、誰にもできないな。
282:login:Penguin
06/12/19 18:18:42 GWNB1OAW
住んでいるまちの警察の動向が怪しいなら
結構長くでてこれないかもね。
283:login:Penguin
06/12/19 20:14:25 b8knrZg8
>>280
もっとも、安定性を求めるのならLinuxなんか使うなって話もあるわけで。
284:login:Penguin
06/12/19 20:17:30 qiS7ynEf
hahahahahahahahahahhahahahahahahaha
285:netadesu
06/12/19 20:37:18 oCGBR2+N
>>270
各ファイルシステムとも4byteのマジックコードを定義してるので
それで判別できる。ただし実際に判別してちゃんと読み書き時に
変換してるかは別。
FSじゃないけど0xCAFEBABEとか0xDEADBEEFとかが有名。
0xCAFEBABE 0xBEBAFECA 0xBABECAFE 0xFECABEBA
と読んだ時に違いが出るので判定できる・・・んだけど64bitの
足音が近いから変態なアーキテクチャが出たりしたら8byteマジックが
必要となる日も近いかも。
286:login:Penguin
06/12/19 20:44:56 WLeCaQbI
>>283
そんな話いつどこで聞いたんだ。捏造するな。
287:login:Penguin
06/12/19 20:57:01 azfMKvlf
ID:WLeCaQbI発狂中
288:login:Penguin
06/12/19 22:27:06 //1HgQEi
sun386i と sun3 の disk の繋ぎかえはダメって話だったな
289:login:Penguin
06/12/19 23:12:48 LR+FoNiH
結局のところ、>>260-261が的を射ているんだな。
で、ビッグエンディアン環境⇔リトルエンディアン環境のディスク移動ってLinuxではほとんどないんじゃねえの？
SunとかMacとかなら要望は多いだろうけど。
290:login:Penguin
06/12/19 23:40:54 leiixtBd
スラッシュドット ジャパン | LeopardはZFS対応か?
URLﾘﾝｸ(slashdot.jp)
刻はZFSの鼓動を見る。たぶん。
URLﾘﾝｸ(blog.ninth-nine.com)
291:login:Penguin
06/12/19 23:56:10 LBOK3XqF
>>289
i386 <-> ppc ならありえるレベルだと思う。
というか自分では使っている。
まあalpha,sparcあたりも死んでは無いしな。
292:login:Penguin
06/12/20 00:06:07 K8chhcW1
>>291
i386 <-> ppcって
Vineでも使われてるんですか？
293:login:Penguin
06/12/20 00:09:26 K8chhcW1
まあディス鳥はどうでもいいけど、実際にディスクつなぎ変えるの？
294:login:Penguin
06/12/20 00:19:13 MV22v5Iu
PPCはNAS使ってる一部の勘違いさん御用達。
295:login:Penguin
06/12/20 07:45:13 yU/fzyFw
>>285
> 各ファイルシステムとも4byteのマジックコードを定義してるので
ソース希望
各ファイルシステムで定義するというのはOSのデザインがおかしいと思う
VFSで定義して、各ファイルシステムで実装というのがあるべき姿と思うんだが
296:login:Penguin
06/12/20 07:56:57 yU/fzyFw
というかパーティションテーブルでも同じ問題は起こる
ここを読めないとファイルシステムも読めない
つまり、ファイルシステムを読む段階ではKernelはバイトオーダーを知っていないといけない
こういう問題もあると思うんだが
297:login:Penguin
06/12/20 08:14:22 NEgx20b5
そういえば玄箱とかもPPCだっけ。
298:login:Penguin
06/12/20 10:42:29 TN7cgs5A
>つまり、ファイルシステムを読む段階ではKernelはバイトオーダーを知っていないといけない
linux/fs/* を見ると le32_to_cpu とか be32_to_cpu とかかいてある。
ほとんどはLEだけど、メジャーどこだとxfsがBEだな。
299:login:Penguin
06/12/20 10:53:47 biQx0lWY
>>295
スマソ。全部がというつもりではなくて、fsの多くは独自に
マジックコードを持ってるというつもりで書いた。OS/VFSとかが
マジックがないとダメと規定してるわけではないです。
300:login:Penguin
06/12/20 11:16:07 yU/fzyFw
>>298
> linux/fs/* を見ると le32_to_cpu とか be32_to_cpu とかかいてある。
？
何か勘違いしてるみたいだけど、もう一度言いますよ
パーティションテーブルはファイルシステムを使わず直接ディスクに書き込んである。
ファイルシステムが読めてるって事は、その前に既にバイトオーダーを正しく読んでいるって事が言いたいんですが。
301:login:Penguin
06/12/20 15:42:40 CiR8D7Mp
>>292
Vineは使っていない。
>>300
基本的かもしれないが質問。
パーティションテーブルに書くときのバイトオーダはnative？
302:300
06/12/20 15:49:05 yU/fzyFw
>>301
> パーティションテーブルに書くときのバイトオーダはnative？
多分そう言われるだろうなと思った。
まあ、>>300の内容は当然そう思っているから。
詳しい人よろしく頼む。
303:300
06/12/20 15:59:29 yU/fzyFw
１つ忘れてた。
x86の場合はネイティブだったと思う。
ちょっとサイト探してみる。
304:login:Penguin
06/12/20 15:59:35 3ugUm6GB
パーティションテーブルって一口に言っても
305:300
06/12/20 16:10:54 yU/fzyFw
URLﾘﾝｸ(www.ata-atapi.com)
これMS-DOSのブートセクタ。
当然FDだけど。
バイナリエディタでちゃんとアスキー文字が読めているので、バイトオーダはnativeなはず。
まあ、パーティションテーブルだけ反対とか、HDがFDと違う方法を使うとかありえない訳じゃない。
あくまで参考。
306:300
06/12/20 16:56:18 yU/fzyFw
HDの場合
URLﾘﾝｸ(www.ata-atapi.com)
01 01 00が第一パーティションのスタートCHS
URLﾘﾝｸ(www.ata-atapi.com)
実際のパーティションは先頭セクタがMBRなのでCHS=0,1,1から始まる。
01 01 00が0,1,1を表しているからリトルエンディアン。
x86の場合はネイティブ。
ビッグエンディアンの場合がわからない．．．
307:login:Penguin
06/12/20 17:40:47 iqnu0UKk
>>306
さあ、bigなマシンを調達してくるんだ。
308:login:Penguin
06/12/20 17:42:33 fcZO1G6Z
そこでqemuですよ
309:300
06/12/20 17:52:46 yU/fzyFw
>>308
サンクス
310:300
06/12/20 22:52:54 yU/fzyFw
誰か技量のある人、ビッグエンディアンの検証頼む。
俺もやるけど、簡単じゃない。
パーティションテーブルの仕様もよくわからない。
Qemuもまだ動いてるだけだ。
311:300
06/12/20 22:59:15 yU/fzyFw
多分Sparcの方が資料は多い。
パーティションテーブルは先頭セクタでBSD流のスライスが書いてある。
でも、それ以上の資料が無い。
312:login:Penguin
06/12/20 23:13:46 npYLopAO
XFSはビッグエンディアンのマシンとリトルエンディアンのマシンではジャーナルログの互換性が無いからxfs_repair -Lでログを消す必要があるとドキュメントに書いてある。
元々はIRIXに接続されていたストレージをＡｌｔｉｘに接続するためだったんだけどね
313:login:Penguin
06/12/21 00:40:44 LN3BUO6p
zfs importってやるとSPARCで作成したZFSファイルシステムをx64のマシンで
使えるようになるんだってさ。
314:login:Penguin
06/12/21 13:11:34 1QKYJ/dy
伝統的な dump/restore でのバックアップを
MySQL などの RDBMS が動いているマシンで
行ううえでの問題点は何でしょうか？
データベースのファイルは随時更新されているので
dump/restore ではまったく意味がないのでしょうか？
315:login:Penguin
06/12/21 13:46:14 5fo5L+zb
mysqlのバックアップをわざわざdump/restoreで行う必要はないだろう。
tarなどのファイル単位バックアップでOK。
＞データベースのファイルは随時更新されているので
DBのバックアップはDBを止めて行うのが基本。
dump/restoreにしろ、tarにしろDBを止めないと整合性のとれた状態でのバックアップは不可能。
要件的に止められない場合に、DBMSに用意されているオンラインバックアップなどを検討する。
316:login:Penguin
06/12/21 14:39:14 +wTFdS6A
>>314
> データベースのファイルは随時更新されているので
> dump/restore ではまったく意味がないのでしょうか？
URLﾘﾝｸ(dev.mysql.com)
RDBMSの設計者もバカではないから、随時更新されている程度の事はわかってるよ。
-F, --flush-logs
ダンプを開始する前に、MySQL サーバ内のログファイルをフラッシュする。
注意: このオプションを --all-databases（または -A）オプションと組み合わせて使用した場合、
ログは各データベースのダンプごとにフラッシュされる。
-l, --lock-tables.
ダンプを開始する前にすべてのテーブルをロックする。
テーブルは READ LOCAL でロックされ、
MyISAM テーブルの場合は同時挿入が可能になる。
注意: 複数のデータベースをダンプする場合、--lock-tables は各データベースを個別にロックする。
したがって、このオプションを使用した場合、
データベース間でのテーブルの論理整合性は保証されない。
異なるデータベースのテーブルは、
完全に異なる状態でダンプされる可能性がある。
更新中なのが、前提なのがよくわかるだろう。
実際のところどうしたらいいかは、経験が豊富な人間に聞くしかない。
このスレで質問しても大した事は聞けないよ。
DBの板で質問するべき。
317:login:Penguin
06/12/21 14:49:40 wTdtL7fh
dump違い
318:login:Penguin
06/12/21 14:59:03 +wTFdS6A
MySQLは更新関係にはやはり少し弱い。
Oracleでバックアップコマンドを発行すると、全データベースがロックされ整合性が保証される。
319:login:Penguin
06/12/21 15:12:58 +wTFdS6A
URLﾘﾝｸ(dev.mysql.com)
こっちの方が基本かも。
こちらもちゃんと、更新中であることを前提に書かれている。
320:login:Penguin
06/12/21 16:55:40 5fo5L+zb
＞Oracleでバックアップコマンドを発行すると、全データベースがロックされ整合性が保証される。
思いっきり間違い。
321:login:Penguin
06/12/21 17:23:46 +wTFdS6A
>>314
> 伝統的な dump/restore でのバックアップを
マジ勘違いすまそ
>>320
> 思いっきり間違い。
確かに間違ってますハイ
漏れの場合は表領域デフォルトしか使わなかったので、全データベースのロックもできたけどこれはレアケース
322:login:Penguin
06/12/21 17:29:36 WSqxjtJx
>>316
そりゃDBのダンプやん。スレ違いってことが認識できない知能の持ち主の314が
言っているのはfsのdump/restoreでそ。
>>318-320
スレ違いだから、知能障害者の314は放置してもう止めませう。
323:login:Penguin
06/12/21 19:19:12 gemQUBxV
>>321
全データベースか、特定表領域かの違いではない。
ロックしてしまったら、サービス継続上の問題になる。
ブロックの変更情報がREDOログに書き込まれるようになり、
表領域がホットバックアップ可能状態になるってことだと思う。
324:login:Penguin
06/12/21 19:50:34 5fo5L+zb
話を少し戻すと、DBMSなどのバックアップを
ストレージの3rdミラー（TimeFinderやMRCFなど）を使用することを想定すると、
「Linuxのsyncコマンドでは同期の保証がされない？」ってのは少し気になる問題ではある。
通常、3rdミラーバックアップは、本番機側でsyncを掛けた直後にミラーをスプリットするので、
スプリットされたボリュームのファイルシステムがきちんと整合性取れるのかどうか、ちと不安。
いままで、UnixとWindowsでしか、3rdミラーを使ったシステムを手がけたことがないから、
Linuxリプレイスが基幹系に及んできたらどうなるんだろうか。
325:login:Penguin
06/12/21 19:53:34 4grny1OI
またsyncコマンドか
奥なんとかさん、出番ですよ。
326:login:Penguin
06/12/21 20:02:32 BadC1Qip
>>325
包茎くん乙
もう二度と湧いて出てこないでね。臭いんで。
327:login:Penguin
06/12/21 20:56:54 eQeBXR6E
>>324
> Linuxリプレイスが基幹系に及んできたらどうなるんだろうか。
東証と富士通は Itanium+Linux で行くらしいよ。取引システムの
処理能力がさんざ問題にされたから、そちらを重視なんだろうけど。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
328:login:Penguin
06/12/21 21:03:57 WbIkO1iK
>>324
> 「Linuxのsyncコマンドでは同期の保証がされない？」ってのは少し気になる問題ではある。
Oracleもこの事の真偽ぐらいは当然知っていると思うから、
もし保証されないのであれば、放置はしていないと思う。
umountで同期できるんだから、同期できないはずはないと思う。
rawデバイス使用時の問題も、含めて。
329:login:Penguin
06/12/22 16:04:30 WqL6S9ur
妻の殺害容疑で勾留中のHans Reiser、Namesysを売却方針
URLﾘﾝｸ(slashdot.jp)
330:login:Penguin
06/12/22 16:13:04 DsPvjvvV
これはもうだめかもしれんね
331:login:Penguin
06/12/22 16:36:02 /iCqG6bS
ReiserFSのためにはむしろいいことかもよ。
彼は優秀な技術者だけど、トラブルメーカーだった。
332:login:Penguin
06/12/22 17:42:56 /1j0azIV
天才が抜けた穴が簡単に埋まるとは思えんがな。
333:login:Penguin
06/12/22 19:00:59 Co7/GRNn
無実を証明するからだれか金を援助してくれ。
一応形式的にだが会社をやるよ。
無実を証明したらまた俺が開発してやるよ。
魅力的なプランだろ？
こんな感じだと思う。
開発するのはアナルだけど。
334:login:Penguin
06/12/22 19:03:52 opUYRnYx
>>333
(;´Д｀)ﾊｧﾊｧ
335:login:Penguin
06/12/22 22:41:01 2mRPP6sE
話ぶった切って悪いんだけど
分散ファイルシステムの話題はここでおｋ？それとも別の場所あるのかしら。
336:login:Penguin
06/12/22 22:43:42 LHAWvpAd
>>335
ここでやっちゃっていいんじゃない？
337:login:Penguin
06/12/22 22:51:33 /iCqG6bS
> 天才が抜けた穴が簡単に埋まるとは思えんがな。
Reiser4はもう基本はできてるだろう。
後は若いPGの仕事でしょ。
Reiser5以降の事は知らない。
これは彼が捕まっていなくてもわからないし、会社を売ってなくてもわからない。
338:login:Penguin
06/12/22 23:32:19 2mRPP6sE
ここでいいか。ではとりあえず・・。
分散ファイルシステムにはAFS（OpenAFS，Arla），Coda，InterMezzoとあるみたいなんだけど，
現状では機能面だとこうで
InterMezzo ＞ Coda ＞ AFS
安定性でみるとこう
AFS ＞ Coda ＞ InterMezzo
こんなんであってる？
あと，NFSv4とかも比較にいれたほうがいいんだろうか。
339:login:Penguin
06/12/23 01:59:13 v667gEsO
>>338
Cleversafe は?
340:login:Penguin
06/12/23 02:20:21 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
06/12/23 10:07:11 pzaVswcy
未だに、NFSv3をUDPで使ってます。
342:login:Penguin
06/12/23 10:43:55 yHT154ws
UDPはUDPでメリット無いのかな？
負荷分散とかしやすそうなイメージがある（イメージだけで裏は取ってない）。
343:login:Penguin
06/12/23 11:09:44 Z2SBvvTY
UDPだから、転送速度が上がるとかｗ
これもあてずっぽう。
344:login:Penguin
06/12/23 11:54:29 /zNuBneV
>>339
Cleversafeって実用に耐えるの？
345:login:Penguin
06/12/23 21:55:41 MNgpS4hJ
メリットがあるから UDP 使ってた訳だが
346:login:Penguin
06/12/24 12:25:32 QbyLMMQt
>>340
softupdateは効かせてある？
それとuser timeに違いがあるのが気になる。同じになるはず。
347:login:Penguin
06/12/24 12:28:30 QbyLMMQt
UDPだとTCPをおしのけて通信できる
でもGbEを使いきろうとするとTCPのような細かい制御が必要。
348:login:Penguin
06/12/24 15:03:41 VUeVRThv
>でもGbEを使いきろうとするとTCPのような細かい制御が必要。
ォィォィ
349:login:Penguin
06/12/24 15:05:47 VUuQmegh
>>347
> でもGbEを使いきろうとするとTCPのような細かい制御が必要。
ウソつくな。
350:login:Penguin
06/12/24 15:17:50 lyOxSAlM
使いきりたいならUDP一択だろ
351:300
06/12/24 15:24:13 xYVNmyrQ
ちわ。
お久しぶりです。
ビッグエンディアンの検証ですが、途中で止まっています。
QemuにPPC版Debianのインスコまでは終わりましたが、アップルパーティションマップの仕様が全く見つからず。
仕方がないので、カーネルソースの中を探していて面白いものを見つけました。
352:300
06/12/24 15:25:54 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
06/12/24 15:28:25 xYVNmyrQ
linux/fs/partitions/mac.h
#define MAC_PARTITION_MAGIC0x504d
354:300
06/12/24 15:29:44 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
06/12/24 15:38:08 xYVNmyrQ
ちょっと、読みづらくてすまそ。
>>352の
__be16signature;/* expected to be MAC_PARTITION_MAGIC */
は
__be16 signature; /* expected to be MAC_PARTITION_MAGIC */
がコピペでつぶれてしまった。
これってマジックバイトがパーティションテーブルに書き込まれているように思えるんだけど。
それなら、fsが読む事と、パーティションテーブルを読むことの後先のつじつまが合うんじゃね？
後、アップルパーティションマップの仕様を知っている人は情報を希望。
356:300
06/12/24 15:51:34 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
06/12/24 16:29:15 xYVNmyrQ
マジックバイトの話よりこちらの方が重要かな。
>>352を見るとデータはほとんど __be16 か __be32 で渡されている。
マックのパーティションを読む場合に限ればパーティションテーブルの読み込みは、
ビッグエンディアンの決めうちで行われているように見える。
358:300
06/12/24 20:12:13 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
06/12/25 21:38:37 u5v64fWw
今日も連投マジすまそ。
アップルパーティションマップの仕様を見つけた。
URLﾘﾝｸ(developer.apple.com)
内容はほぼ>>352と同じ。
対象ディス鳥のインスコは
URLﾘﾝｸ(www.ne.jp)
ここを参考に行った。
以下、検証資料を載せる。
360:300
06/12/25 21:40:28 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
06/12/25 21:44:48 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
06/12/25 21:45:28 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
06/12/25 21:48:02 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
06/12/25 21:49:58 u5v64fWw
以上、PPCの場合もネイティブで間違いないと思う。
もう一度謝ります。
連投すまそ。