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

1 名前：login:Penguin [2006/11/25(土) 21:24:41 ID:BgxtdIS9] 過去スレ 01 pc.2ch.net/test/read.cgi/linux/1006743807/ 02 pc5.2ch.net/test/read.cgi/linux/1063025258/ 03 pc8.2ch.net/test/read.cgi/linux/1101495293/ 04 pc8.2ch.net/test/read.cgi/linux/1136695633/ 05 pc8.2ch.net/test/read.cgi/linux/1152348695/ 259 名前：login:Penguin mailto:sage [2006/12/19(火) 12:12:40 ID:JTMTN/tV] >>257 それはVFSレイヤの話でないの？ ファイルシステムに直接依存するのだろうか。 260 名前：login:Penguin mailto:sage [2006/12/19(火) 12:23:30 ID:JTMTN/tV] それは、ビッグエンディアン環境⇔リトルエンディアン環境を移動させればまずいよなあ。 まさに>257の言う事が起こる。 しかし、そうでない場合に>257が言うようなことが起きればVFSの問題と思うんだが。 261 名前：login:Penguin mailto:sage [2006/12/19(火) 12:28:02 ID:JTMTN/tV] とここまで書いておいて気がついた。 何も考えずに書き込み、何も考えずに読み出しても同一環境では問題オコラネー。 VFSもファイルシステムも関係ネー。 違うか？ 262 名前：login:Penguin mailto:sage [2006/12/19(火) 13:04:19 ID:TnIoz1+9] >>258 んなことねえよ ちゃんと考えて設計されてるよ 角度とか 263 名前：login:Penguin mailto:sage [2006/12/19(火) 13:23:33 ID:8O8QeZf3] >>262 ttp://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/1162.html うひひ 264 名前：login:Penguin mailto:sage [2006/12/19(火) 13:31:26 ID:qiS7ynEf] 何このレベル低下っぷり？ 以前はキチガイも多いがここまで低レベルじゃなかっただろこのスレ。 265 名前：login:Penguin mailto:sage [2006/12/19(火) 13:57:36 ID:1t2/+nmt] ext3はOKだと言われているが、他は知らん。 SolarisだとUFSはバイトオーダ依存で、ZFSはバイトオーダ非依存。 266 名前：login:Penguin mailto:sage [2006/12/19(火) 14:21:29 ID:skFd6jjj] ext2をi386と〜ebな環境で使いまわしてるけど、 いまのところ問題は起きてないな。 ただe2fsprogsは全部試していないので、そのへんに 地雷が埋まってるかもしれん。 267 名前：login:Penguin mailto:sage [2006/12/19(火) 14:30:12 ID:O6QzCkRT] >>264 ツマンネ 268 名前：login:Penguin mailto:sage [2006/12/19(火) 14:51:31 ID:LBOK3XqF] >>265 今月のSDにZFSの記事があって、 ZFSは書き込みはマシンバイトオーダ、 読み込み時に変換してると書いてあったな。 269 名前：login:Penguin mailto:sage [2006/12/19(火) 15:52:09 ID:wh6OROKj] >>268 ってことは、ファイルシステムにバイトオーダが記録されてるのかな？ 別のマシンにディスク持って行っても使えるけど バイトオーダが違うマシンに持って行くと動くんだけどパフォーマンスが落ちる、と。 おもしろいかも >>255 すまね。 ひねくれてるのでext3とjfsで作ってみた。 jfsがどれくらい頑丈か、かな・・・・ 取りあえずディスクを直接持って行っての物理的な共有はしないようにします 環境できたらpostmarkでもやってみるよ 270 名前：login:Penguin mailto:sage [2006/12/19(火) 16:34:14 ID:LBOK3XqF] >>269 全くの推測だけどどっかのビットで判別してるんじゃないかな。 0だとLEとか。 記事ではsparcマシンのHDDをintelマシンに持っていっても読める と書いてあったが、パフォーマンスに関しては書いてあったか忘れた。 変換のオーバヘッドはほんの少しだろうけどあるだろうな。 271 名前：login:Penguin mailto:sage [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 mailto:sage [2006/12/19(火) 16:48:06 ID:WLeCaQbI] いまんとこlinux用はext3中心に回ってるんでおk 274 名前：login:Penguin mailto:sage [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 mailto:sage [2006/12/19(火) 17:44:01 ID:qiS7ynEf] 怪しいのは作者が住んでる町の警察の動向だろう 277 名前：login:Penguin mailto:sage [2006/12/19(火) 17:44:48 ID:5KfKfe1m] あれからどうなった 278 名前：login:Penguin mailto:sage [2006/12/19(火) 17:44:55 ID:JTMTN/tV] 確かにナorz 将来乗り換えが必要になる可能性大 279 名前：login:Penguin mailto:sage [2006/12/19(火) 18:07:21 ID:JTMTN/tV] ext3って皆が使ってるから何か起こっても豊富な情報がある。 それにツール類もまずはext3を前提に作られてると思う。 使うのに十分な値打ちがあると思う。 でも、ツマラネーんだよな。 ext3使っててこのスレ読んでても楽しみ少なくない？ 280 名前：login:Penguin mailto:sage [2006/12/19(火) 18:10:57 ID:TnIoz1+9] 楽しみより安定性 281 名前：login:Penguin mailto:sage [2006/12/19(火) 18:17:58 ID:JTMTN/tV] まあ無難な選択を否定することは、誰にもできないな。 282 名前：login:Penguin mailto:sage [2006/12/19(火) 18:18:42 ID:GWNB1OAW] 住んでいるまちの警察の動向が怪しいなら 結構長くでてこれないかもね。 283 名前：login:Penguin mailto:sage [2006/12/19(火) 20:14:25 ID:b8knrZg8] >>280 もっとも、安定性を求めるのならLinuxなんか使うなって話もあるわけで。 284 名前：login:Penguin mailto:sage [2006/12/19(火) 20:17:30 ID:qiS7ynEf] hahahahahahahahahahhahahahahahahaha 285 名前：netadesu mailto:sage [2006/12/19(火) 20:37:18 ID:oCGBR2+N] >>270 各ファイルシステムとも4byteのマジックコードを定義してるので それで判別できる。ただし実際に判別してちゃんと読み書き時に 変換してるかは別。 FSじゃないけど0xCAFEBABEとか0xDEADBEEFとかが有名。 　0xCAFEBABE 0xBEBAFECA 0xBABECAFE 0xFECABEBA と読んだ時に違いが出るので判定できる・・・んだけど64bitの 足音が近いから変態なアーキテクチャが出たりしたら8byteマジックが 必要となる日も近いかも。 286 名前：login:Penguin mailto:sage [2006/12/19(火) 20:44:56 ID:WLeCaQbI] >>283 そんな話いつどこで聞いたんだ。捏造するな。 287 名前：login:Penguin mailto:sage [2006/12/19(火) 20:57:01 ID:azfMKvlf] ID:WLeCaQbI発狂中 288 名前：login:Penguin mailto:sage [2006/12/19(火) 22:27:06 ID://1HgQEi] sun386i と sun3 の disk の繋ぎかえはダメって話だったな 289 名前：login:Penguin mailto:sage [2006/12/19(火) 23:12:48 ID:LR+FoNiH] 結局のところ、>>260-261が的を射ているんだな。 で、ビッグエンディアン環境⇔リトルエンディアン環境のディスク移動ってLinuxではほとんどないんじゃねえの？ SunとかMacとかなら要望は多いだろうけど。 290 名前：login:Penguin mailto:sage [2006/12/19(火) 23:40:54 ID:leiixtBd] スラッシュドット ジャパン | LeopardはZFS対応か? slashdot.jp/mac/06/12/19/0314236.shtml 刻はZFSの鼓動を見る。たぶん。 blog.ninth-nine.com/diary/20061212.txt 291 名前：login:Penguin mailto:sage [2006/12/19(火) 23:56:10 ID:LBOK3XqF] >>289 i386 <-> ppc ならありえるレベルだと思う。 というか自分では使っている。 まあalpha,sparcあたりも死んでは無いしな。 292 名前：login:Penguin mailto:sage [2006/12/20(水) 00:06:07 ID:K8chhcW1] >>291 i386 <-> ppcって Vineでも使われてるんですか？ 293 名前：login:Penguin mailto:sage [2006/12/20(水) 00:09:26 ID:K8chhcW1] まあディス鳥はどうでもいいけど、実際にディスクつなぎ変えるの？ 294 名前：login:Penguin mailto:sage [2006/12/20(水) 00:19:13 ID:MV22v5Iu] PPCはNAS使ってる一部の勘違いさん御用達。 295 名前：login:Penguin mailto:sage [2006/12/20(水) 07:45:13 ID:yU/fzyFw] >>285 >　各ファイルシステムとも4byteのマジックコードを定義してるので ソース希望 各ファイルシステムで定義するというのはOSのデザインがおかしいと思う VFSで定義して、各ファイルシステムで実装というのがあるべき姿と思うんだが 296 名前：login:Penguin mailto:sage [2006/12/20(水) 07:56:57 ID:yU/fzyFw] というかパーティションテーブルでも同じ問題は起こる ここを読めないとファイルシステムも読めない つまり、ファイルシステムを読む段階ではKernelはバイトオーダーを知っていないといけない こういう問題もあると思うんだが 297 名前：login:Penguin mailto:sage [2006/12/20(水) 08:14:22 ID:NEgx20b5] そういえば玄箱とかもPPCだっけ。 298 名前：login:Penguin mailto:sage [2006/12/20(水) 10:42:29 ID:TN7cgs5A] >つまり、ファイルシステムを読む段階ではKernelはバイトオーダーを知っていないといけない linux/fs/* を見ると le32_to_cpu とか be32_to_cpu とかかいてある。 ほとんどはLEだけど、メジャーどこだとxfsがBEだな。 299 名前：login:Penguin mailto:sage [2006/12/20(水) 10:53:47 ID:biQx0lWY] >>295 スマソ。全部がというつもりではなくて、fsの多くは独自に マジックコードを持ってるというつもりで書いた。OS/VFSとかが マジックがないとダメと規定してるわけではないです。 300 名前：login:Penguin mailto:sage [2006/12/20(水) 11:16:07 ID:yU/fzyFw] >>298 >　linux/fs/* を見ると le32_to_cpu とか be32_to_cpu とかかいてある。 ？ 何か勘違いしてるみたいだけど、もう一度言いますよ パーティションテーブルはファイルシステムを使わず直接ディスクに書き込んである。 ファイルシステムが読めてるって事は、その前に既にバイトオーダーを正しく読んでいるって事が言いたいんですが。 301 名前：login:Penguin mailto:sage [2006/12/20(水) 15:42:40 ID:CiR8D7Mp] >>292 Vineは使っていない。 >>300 基本的かもしれないが質問。 パーティションテーブルに書くときのバイトオーダはnative？ 302 名前：300 mailto:sage [2006/12/20(水) 15:49:05 ID:yU/fzyFw] >>301 >　パーティションテーブルに書くときのバイトオーダはnative？ 多分そう言われるだろうなと思った。 まあ、>>300の内容は当然そう思っているから。 詳しい人よろしく頼む。 303 名前：300 mailto:sage [2006/12/20(水) 15:59:29 ID:yU/fzyFw] １つ忘れてた。 x86の場合はネイティブだったと思う。 ちょっとサイト探してみる。 304 名前：login:Penguin mailto:sage [2006/12/20(水) 15:59:35 ID:3ugUm6GB] パーティションテーブルって一口に言っても 305 名前：300 mailto:sage [2006/12/20(水) 16:10:54 ID:yU/fzyFw] www.ata-atapi.com/hiwdos.htm これMS-DOSのブートセクタ。 当然FDだけど。 バイナリエディタでちゃんとアスキー文字が読めているので、バイトオーダはnativeなはず。 まあ、パーティションテーブルだけ反対とか、HDがFDと違う方法を使うとかありえない訳じゃない。 あくまで参考。 306 名前：300 mailto:sage [2006/12/20(水) 16:56:18 ID:yU/fzyFw] HDの場合 www.ata-atapi.com/hiwtab.htm#T2 01 01 00が第一パーティションのスタートCHS www.ata-atapi.com/hiwtab.htm#T7 実際のパーティションは先頭セクタがMBRなのでCHS=0,1,1から始まる。 01 01 00が0,1,1を表しているからリトルエンディアン。 x86の場合はネイティブ。 ビッグエンディアンの場合がわからない．．． 307 名前：login:Penguin mailto:sage [2006/12/20(水) 17:40:47 ID:iqnu0UKk] >>306 さあ、bigなマシンを調達してくるんだ。 308 名前：login:Penguin mailto:sage [2006/12/20(水) 17:42:33 ID:fcZO1G6Z] そこでqemuですよ 309 名前：300 mailto:sage [2006/12/20(水) 17:52:46 ID:yU/fzyFw] >>308 サンクス 310 名前：300 mailto:sage [2006/12/20(水) 22:52:54 ID:yU/fzyFw] 誰か技量のある人、ビッグエンディアンの検証頼む。 俺もやるけど、簡単じゃない。 パーティションテーブルの仕様もよくわからない。 Qemuもまだ動いてるだけだ。 311 名前：300 mailto:sage [2006/12/20(水) 22:59:15 ID:yU/fzyFw] 多分Sparcの方が資料は多い。 パーティションテーブルは先頭セクタでBSD流のスライスが書いてある。 でも、それ以上の資料が無い。 312 名前：login:Penguin mailto:sage [2006/12/20(水) 23:13:46 ID:npYLopAO] XFSはビッグエンディアンのマシンとリトルエンディアンのマシンではジャーナルログの互換性が無いからxfs_repair -Lでログを消す必要があるとドキュメントに書いてある。 元々はIRIXに接続されていたストレージをＡｌｔｉｘに接続するためだったんだけどね 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 mailto:sage [2006/12/21(木) 13:46:14 ID:5fo5L+zb] mysqlのバックアップをわざわざdump/restoreで行う必要はないだろう。 tarなどのファイル単位バックアップでOK。 ＞データベースのファイルは随時更新されているので DBのバックアップはDBを止めて行うのが基本。 dump/restoreにしろ、tarにしろDBを止めないと整合性のとれた状態でのバックアップは不可能。 要件的に止められない場合に、DBMSに用意されているオンラインバックアップなどを検討する。 316 名前：login:Penguin mailto:sage [2006/12/21(木) 14:39:14 ID:+wTFdS6A] >>314 >　データベースのファイルは随時更新されているので >　dump/restore ではまったく意味がないのでしょうか？ 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 mailto:sage [2006/12/21(木) 14:49:40 ID:wTdtL7fh] dump違い 318 名前：login:Penguin mailto:sage [2006/12/21(木) 14:59:03 ID:+wTFdS6A] MySQLは更新関係にはやはり少し弱い。 Oracleでバックアップコマンドを発行すると、全データベースがロックされ整合性が保証される。 319 名前：login:Penguin mailto:sage [2006/12/21(木) 15:12:58 ID:+wTFdS6A] dev.mysql.com/doc/refman/4.1/ja/backup.html こっちの方が基本かも。 こちらもちゃんと、更新中であることを前提に書かれている。 320 名前：login:Penguin mailto:sage [2006/12/21(木) 16:55:40 ID:5fo5L+zb] ＞Oracleでバックアップコマンドを発行すると、全データベースがロックされ整合性が保証される。 思いっきり間違い。 321 名前：login:Penguin mailto:sage [2006/12/21(木) 17:23:46 ID:+wTFdS6A] >>314 >　伝統的な dump/restore でのバックアップを マジ勘違いすまそ >>320 >　思いっきり間違い。 確かに間違ってますハイ 漏れの場合は表領域デフォルトしか使わなかったので、全データベースのロックもできたけどこれはレアケース 322 名前：login:Penguin mailto:sage [2006/12/21(木) 17:29:36 ID:WSqxjtJx] >>316 そりゃDBのダンプやん。スレ違いってことが認識できない知能の持ち主の314が 言っているのはfsのdump/restoreでそ。 >>318-320 スレ違いだから、知能障害者の314は放置してもう止めませう。 323 名前：login:Penguin mailto:sage [2006/12/21(木) 19:19:12 ID:gemQUBxV] >>321 全データベースか、特定表領域かの違いではない。 ロックしてしまったら、サービス継続上の問題になる。 ブロックの変更情報がREDOログに書き込まれるようになり、 表領域がホットバックアップ可能状態になるってことだと思う。 324 名前：login:Penguin mailto:sage [2006/12/21(木) 19:50:34 ID:5fo5L+zb] 話を少し戻すと、DBMSなどのバックアップを ストレージの3rdミラー（TimeFinderやMRCFなど）を使用することを想定すると、 「Linuxのsyncコマンドでは同期の保証がされない？」ってのは少し気になる問題ではある。 通常、3rdミラーバックアップは、本番機側でsyncを掛けた直後にミラーをスプリットするので、 スプリットされたボリュームのファイルシステムがきちんと整合性取れるのかどうか、ちと不安。 いままで、UnixとWindowsでしか、3rdミラーを使ったシステムを手がけたことがないから、 Linuxリプレイスが基幹系に及んできたらどうなるんだろうか。 325 名前：login:Penguin mailto:sage [2006/12/21(木) 19:53:34 ID:4grny1OI] またsyncコマンドか 奥なんとかさん、出番ですよ。 326 名前：login:Penguin mailto:sage [2006/12/21(木) 20:02:32 ID:BadC1Qip] >>325 包茎くん乙 もう二度と湧いて出てこないでね。臭いんで。 327 名前：login:Penguin mailto:sage [2006/12/21(木) 20:56:54 ID:eQeBXR6E] >>324 > Linuxリプレイスが基幹系に及んできたらどうなるんだろうか。 東証と富士通は Itanium+Linux で行くらしいよ。取引システムの 処理能力がさんざ問題にされたから、そちらを重視なんだろうけど。 itpro.nikkeibp.co.jp/article/NEWS/20061219/257264/ 328 名前：login:Penguin mailto:sage [2006/12/21(木) 21:03:57 ID:WbIkO1iK] >>324 >　「Linuxのsyncコマンドでは同期の保証がされない？」ってのは少し気になる問題ではある。 Oracleもこの事の真偽ぐらいは当然知っていると思うから、 もし保証されないのであれば、放置はしていないと思う。 umountで同期できるんだから、同期できないはずはないと思う。 rawデバイス使用時の問題も、含めて。 329 名前：login:Penguin mailto:sage [2006/12/22(金) 16:04:30 ID:WqL6S9ur] 妻の殺害容疑で勾留中のHans Reiser、Namesysを売却方針 slashdot.jp/linux/article.pl?sid=06/12/22/0642220&from=rss 330 名前：login:Penguin mailto:sage [2006/12/22(金) 16:13:04 ID:DsPvjvvV] これはもうだめかもしれんね 331 名前：login:Penguin mailto:sage [2006/12/22(金) 16:36:02 ID:/iCqG6bS] ReiserFSのためにはむしろいいことかもよ。 彼は優秀な技術者だけど、トラブルメーカーだった。 332 名前：login:Penguin mailto:sage [2006/12/22(金) 17:42:56 ID:/1j0azIV] 天才が抜けた穴が簡単に埋まるとは思えんがな。 333 名前：login:Penguin mailto:sage [2006/12/22(金) 19:00:59 ID:Co7/GRNn] 無実を証明するからだれか金を援助してくれ。 一応形式的にだが会社をやるよ。 無実を証明したらまた俺が開発してやるよ。 魅力的なプランだろ？ こんな感じだと思う。 開発するのはアナルだけど。 334 名前：login:Penguin mailto:sage [2006/12/22(金) 19:03:52 ID:opUYRnYx] >>333 (;´Д｀)ﾊｧﾊｧ 335 名前：login:Penguin mailto:sage [2006/12/22(金) 22:41:01 ID:2mRPP6sE] 話ぶった切って悪いんだけど 分散ファイルシステムの話題はここでおｋ？それとも別の場所あるのかしら。 336 名前：login:Penguin mailto:sage [2006/12/22(金) 22:43:42 ID:LHAWvpAd] >>335 ここでやっちゃっていいんじゃない？ 337 名前：login:Penguin mailto:sage [2006/12/22(金) 22:51:33 ID:/iCqG6bS] >　天才が抜けた穴が簡単に埋まるとは思えんがな。 Reiser4はもう基本はできてるだろう。 後は若いPGの仕事でしょ。 Reiser5以降の事は知らない。 これは彼が捕まっていなくてもわからないし、会社を売ってなくてもわからない。 338 名前：login:Penguin mailto:sage [2006/12/22(金) 23:32:19 ID:2mRPP6sE] ここでいいか。ではとりあえず・・。 分散ファイルシステムにはAFS（OpenAFS，Arla），Coda，InterMezzoとあるみたいなんだけど， 現状では機能面だとこうで InterMezzo ＞ Coda ＞ AFS 安定性でみるとこう AFS ＞ Coda ＞ InterMezzo こんなんであってる？ あと，NFSv4とかも比較にいれたほうがいいんだろうか。 339 名前：login:Penguin mailto:sage [2006/12/23(土) 01:59:13 ID:v667gEsO] >>338 Cleversafe は? 340 名前：login:Penguin mailto:sage [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 mailto:sage [2006/12/23(土) 10:07:11 ID:pzaVswcy] 未だに、NFSv3をUDPで使ってます。 342 名前：login:Penguin mailto:sage [2006/12/23(土) 10:43:55 ID:yHT154ws] UDPはUDPでメリット無いのかな？ 負荷分散とかしやすそうなイメージがある（イメージだけで裏は取ってない）。 343 名前：login:Penguin mailto:sage [2006/12/23(土) 11:09:44 ID:Z2SBvvTY] UDPだから、転送速度が上がるとかｗ これもあてずっぽう。 344 名前：login:Penguin mailto:sage [2006/12/23(土) 11:54:29 ID:/zNuBneV] >>339 Cleversafeって実用に耐えるの？ 345 名前：login:Penguin mailto:sage [2006/12/23(土) 21:55:41 ID:MNgpS4hJ] メリットがあるから UDP 使ってた訳だが 346 名前：login:Penguin mailto:sage [2006/12/24(日) 12:25:32 ID:QbyLMMQt] >>340 softupdateは効かせてある？ それとuser timeに違いがあるのが気になる。同じになるはず。 347 名前：login:Penguin mailto:sage [2006/12/24(日) 12:28:30 ID:QbyLMMQt] UDPだとTCPをおしのけて通信できる でもGbEを使いきろうとするとTCPのような細かい制御が必要。 348 名前：login:Penguin mailto:sage [2006/12/24(日) 15:03:41 ID:VUeVRThv] >でもGbEを使いきろうとするとTCPのような細かい制御が必要。 ォィォィ 349 名前：login:Penguin mailto:sage [2006/12/24(日) 15:05:47 ID:VUuQmegh] >>347 > でもGbEを使いきろうとするとTCPのような細かい制御が必要。 ウソつくな。 350 名前：login:Penguin mailto:sage [2006/12/24(日) 15:17:50 ID:lyOxSAlM] 使いきりたいならUDP一択だろ 351 名前：300 mailto:sage [2006/12/24(日) 15:24:13 ID:xYVNmyrQ] ちわ。 お久しぶりです。 ビッグエンディアンの検証ですが、途中で止まっています。 QemuにPPC版Debianのインスコまでは終わりましたが、アップルパーティションマップの仕様が全く見つからず。 仕方がないので、カーネルソースの中を探していて面白いものを見つけました。 352 名前：300 mailto:sage [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 mailto:sage [2006/12/24(日) 15:28:25 ID:xYVNmyrQ] linux/fs/partitions/mac.h #define MAC_PARTITION_MAGIC0x504d 354 名前：300 mailto:sage [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 mailto:sage [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 mailto:sage [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 mailto:sage [2006/12/24(日) 16:29:15 ID:xYVNmyrQ] マジックバイトの話よりこちらの方が重要かな。 >>352を見るとデータはほとんど __be16 か __be32 で渡されている。 マックのパーティションを読む場合に限ればパーティションテーブルの読み込みは、 ビッグエンディアンの決めうちで行われているように見える。 358 名前：300 mailto:sage [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 mailto:sage [2006/12/25(月) 21:38:37 ID:u5v64fWw] 今日も連投マジすまそ。 アップルパーティションマップの仕様を見つけた。 developer.apple.com/documentation/mac/Devices/Devices-121.html#MARKER-2-27 内容はほぼ>>352と同じ。 対象ディス鳥のインスコは www.ne.jp/asahi/open/gallery/qemuonwin/qowdebianppc/qowdebianppc.htm ここを参考に行った。 以下、検証資料を載せる。

---

---

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

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef