[過去ﾛｸﾞ]
/**ファイルシステム総合スレ その3**/ (983ﾚｽ)
/**ファイルシステム総合スレ その3**/ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
652: login:Penguin [sage] 2005/06/21(火) 15:18:02 ID:MeWT+wmb >>648 じゃあ洩れも買おう。 FSの基本とかアルゴリズムなど不変な部分は教科書的に書いて、 実践編をこまめに改訂できれば良書になりそう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/652
653: login:Penguin [sage] 2005/06/21(火) 16:30:37 ID:bsn0xczT wiki に 1 日 1 ページ書いていけば？ 報酬ならジャムおじさん方式で。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/653
654: login:Penguin [sage] 2005/06/22(水) 00:31:21 ID:q++h9cos >>643 こんなの見つけた。 やっぱりネットワークバイトオーダーと同じでLittle Endianに してるんだね。 http://www.linux-m68k.org/ext2swap.html http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/654
655: login:Penguin [sage] 2005/06/22(水) 01:46:41 ID:ffTWYDdq 一応。 ネットワークバイトオーダーはビッグエンディアン。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/655
656: 654 [sage] 2005/06/22(水) 03:38:04 ID:q++h9cos >>655 orz ｻﾝｸｽ。 何言ってんだｵﾚ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/656
657: login:Penguin [sage] 2005/06/22(水) 13:36:08 ID:1+WehZ3c >>620 すぐに試してみる心意気はすばらしいと思うんですが、 ファイルシステムよりforkが律速段階になっている気がする。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/657
658: login:Penguin [sage] 2005/06/22(水) 15:44:46 ID:kPbVU8pP >>635 ttp://lkml.org/lkml/2005/6/21/98 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/658
659: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/06/22(水) 23:34:50 ID:YmIV6emW 詳解ファイルシステム >>653 wikiでコツコツ作っていきます。(=ﾟωﾟ)ﾉ 本の出版はしたことがない素人なので、 wikiでも良いかなってことで ＃wikiも本格的に触ったことないんで、勉強しながらですけど。。 zfsが秋ぐらいに出るかもしれないので、 そのぐらいまでに形になっていければいいかな？ とりあえず、今日少しだけ書いてみた。 ファイルシステム諸言とvfsについて ファイルシステム諸言は書いてないけどia-64の場合ですので ia-32のほうが利用者多いのでのちほど書きます。 ttp://www.wikihouse.com/linuxfs ＃内容は期待しないでください。。。。 文章考えるのが大変。。 参考文献→linux-2.6.12.tar.bz2 一から作ってるので、オリジナルだと思うけど、どこかに 似た文章があったら教えてください。書き直します。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/659
660: login:Penguin [sage] 2005/06/23(木) 00:23:51 ID:gj5NJeBd おいおい がんばっちゃってよ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/660
661: login:Penguin [sage] 2005/06/23(木) 01:10:05 ID:ulPMUhXL 体壊すなよ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/661
662: login:Penguin [sage] 2005/06/23(木) 01:23:25 ID:LWBQJQ1j 諸言？諸元？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/662
663: login:Penguin [sage] 2005/06/23(木) 01:42:31 ID:Bb2DfQHA かなり期待。 もしミスや誤字その他で気になることがあっても 追い追いこのスレで話しながら直していけばよいでしょう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/663
664: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/06/23(木) 01:45:36 ID:cGInpt1v >>662 諸言は誤字です。諸元です。。 直しました。ご指摘ありがとうございますm(__)m vfsについて少し追加(各operations系[fs.h])しました。 ＃絵も一部欠けてたり。。直さなきゃ。。。 ところで、今作ってる「詳解ファイルシステム」って こんな感じで作成し続けて良いのかな？ 細かいところはかなり省いているんだが。。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/664
665: login:Penguin [sage] 2005/06/23(木) 20:45:06 ID:JZIHc1es doxygen した方が早いような http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/665
666: login:Penguin [sage] 2005/06/24(金) 08:11:22 ID:m8AQpDgt 同じ指摘ばかりで申し訳ないですが, 「1ディレクトリに10000ファイルを置くテスト」のように, 10000回touchをforkしていると, 時間の大半はforkに かかってしまい, ファイルシステムのテストにはならない気がします. たとえば, seq 1 10000 | xargs touch だと, 私の環境では, 35倍速くなりました. さらに, 専用の小さなプログラム書けば, もっと速くなって, ファイルシステム自体の速度を見るのに役立つと思います. http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/666
667: 666 [sage] 2005/06/24(金) 08:24:18 ID:m8AQpDgt 参考までにforkが1回になるようにやってみました. Cで以下のようなプログラムだと, さらに2倍(元の70倍)でした. int main(int ac, char **av) { char name[10]; int fd,i; if (ac < 2) exit (1); i = atoi(*(av+1)); while (i--) { sprintf (name, "%d", i); fd = creat(name, 00644); close(fd); } } ./a.out 10000 perl だと, seq | xargs と同じくらい. perl -e 'for($i=0;$i<10000;$i++){open $fh, ">$i";close $fh}' xargs がお気楽という点で良いかもしれませんね. http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/667
668: login:Penguin [age] 2005/06/24(金) 12:16:38 ID:tsef+KUk 各ファイルシステム間のファイルのコピーってどのように行われているのですか？ パーミッションやファイルサイズ、アクセス時間などをどうやって移動させているかわかりません。 できればkernel2.6、ファイルシステムはext2で具体的に教えてほしいです。お願いします。 参考HP、参考書籍などありましたら、リンクをお願いします。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/668
669: login:Penguin [sage] 2005/06/24(金) 12:37:45 ID:gUOPp5+p GNU fileutilsに含まれるcp(1)のソースを見よ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/669
670: login:Penguin [sage] 2005/06/24(金) 12:39:50 ID:IMmM9dp+ >>668 学校の課題なら自分で調べましょうね http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/670
671: login:Penguin [sage] 2005/06/24(金) 12:56:30 ID:/0PwhOb0 >>659 vfsの絵はreadからすぐにカーネルに入ってもいいような気がする。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/671
672: login:Penguin [sage] 2005/06/24(金) 15:09:06 ID:Ml81310x Reiserﾀﾝ... ｶﾞﾝ( ﾟдﾟ)ｶﾞﾚ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/672
673: login:Penguin [sage] 2005/06/24(金) 20:00:43 ID:tsef+KUk >>669 ありがとうございます。 解決しました。m(_ _)mペコリ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/673
674: login:Penguin [sage] 2005/06/25(土) 04:51:08 ID:lnyqA92V http://www.microsoft.com/japan/msdn/library/ja/jpdnw2k/htm/ntfs2.asp NTFSはsparse fileをサポートしてます。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/674
675: login:Penguin [sage] 2005/06/25(土) 05:15:42 ID:wSJuiDDs 突然何を言うか http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/675
676: login:Penguin [sage] 2005/06/25(土) 10:53:29 ID:8VQiwdit >>675 >>659 の内容についてだと思う。 Linux のカーネルを元に書いてるから、 Windows 関連について不正確な箇所がある。 そこらへんはゆっくり検証していくしかない。 FAT のファイル数制限の検証をしようとしてるけど 遅すぎてまだ終わっていない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/676
677: login:Penguin [sage] 2005/06/25(土) 11:23:05 ID:RIAq5/dk FATは仕様上ルート以外の制限ないんじゃない？ もちろんあるかもしれない実装上の制限を調べたいんなら別だけど。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/677
678: login:Penguin [sage] 2005/06/25(土) 11:45:15 ID:tjGxthTu FATは同一ディレクトリに多数のファイルを置くと 新規作成/削除が目に見えて遅くなるね。 １つ作るのに秒単位で時間がかかる。 もし、ファイルシステム全体での制限を調べているのであれば 今からでも、ディレクトリを細かく分けてテストすることを勧めたい。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/678
679: login:Penguin [sage] 2005/06/25(土) 12:21:46 ID:0zWHwOtL 詳解ファイルシステム？ つttp://www.namesys.com/benchmarks.html http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/679
680: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/06/25(土) 12:43:23 ID:WWJmgvXR 指摘をしていただける皆様方ありがとうございますm(_ _)m どんどん反映して良いものに作り上げたいです。 ＃良いものが出来れば、ここのテンプレに載せてもらえるかな(￣ー￣)ﾆﾔﾘ >>666 「1ディレクトリに10000ファイルを置くテスト」 ご指摘ありがとうです。m(_ _)m 1fileをcreateする速度は今のところ 速い 遅い reiserfs > jfs > ext2 > xfs > ext3 > vfat と書いてます。 専用の測定プログラムを書けば、速度は速くなりますが 速いファイルシステム、遅いファイルシステムの順番は変わりますか？ 目的はどのファイルシステムが速いのかを調べることです。 なので、測定プログラム(コマンド)は何でも良いかなと考えております。 1createで何milli secかかるか測定するものではありません。 環境や測定プログラムによってmilli secは変化しすぎるから。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/680
681: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/06/25(土) 12:43:42 ID:WWJmgvXR >> 674 >>676の言うとおり、Linuxのカーネルを元に書いてます。 windows上ではsparse fileをサポートしているが、linuxではまだ サポートしきれておりません。 linux2.6.12.1/fs/ntfs/inode.cの中で、ntfs_truncateで検索してみてると * ntfs_truncate - called when the i_size of an ntfs inode is changed * @vi:inode for which the i_size was changed * * We do not support i_size changes yet. とあるし。 詳解ntfsに記述しておきます。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/681
682: login:Penguin [sage] 2005/06/25(土) 15:13:48 ID:CMAYG4ue >680 >専用の測定プログラムを書けば、速度は速くなりますが >速いファイルシステム、遅いファイルシステムの順番は変わりますか？ forkなどで律速になったら有意な差が検出できない可能性はある。 またドライバの癖が出る可能性もありそう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/682
683: login:Penguin [sage] 2005/06/25(土) 15:52:43 ID:0zWHwOtL >>680 > 専用の測定プログラムを書けば、速度は速くなりますが > 速いファイルシステム、遅いファイルシステムの順番は変わりますか？ > > 目的はどのファイルシステムが速いのかを調べることです。 > なので、測定プログラム(コマンド)は何でも良いかなと考えております。 > > 1createで何milli secかかるか測定するものではありません。 > 環境や測定プログラムによってmilli secは変化しすぎるから。。 何がしたいのかよく分かりませんな。 君は各ファイルシステムが採用しているデータ構造をサーベイして*ステップ数*で 評価しようとしているのではなかったのか。厳密なステップ数ではなくて計算量オーダーでも別に構わないが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/683
684: 666 [sage] 2005/06/25(土) 16:08:01 ID:/kSYTAkX >>680 元の測定だと99%以上の時間がファイルシステム以外で使われています. 順序を知るのが目的だとして, それら99%分の処理が常に同じ時間で 終えるものであれば, 元の測定方法でも問題ないと思います. ただ, 現実にはforkの時間は結構幅があるような気がします. 後で実際に試してみます. http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/684
685: 666 [sage] 2005/06/25(土) 16:14:38 ID:/kSYTAkX > ただ, 現実にはforkの時間は結構幅があるような気がします. > 後で実際に試してみます. やってみました: (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.96s system 101% cpu 11.137 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.37s user 10.02s system 103% cpu 11.044 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 10.01s system 102% cpu 11.044 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.39s user 9.97s system 102% cpu 11.041 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 9.99s system 102% cpu 11.034 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.43s user 9.93s system 102% cpu 11.048 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.95s system 102% cpu 11.040 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.97s system 101% cpu 11.140 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 10.01s system 101% cpu 11.150 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.37s user 10.01s system 103% cpu 11.035 total まあ, 無視できる誤差と言っても良いのかなあ… # とはいえ釈然としないものはありますが. http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/685
686: login:Penguin [sage] 2005/06/25(土) 20:51:15 ID:22AYPrE9 >>677 ルート以外もあるよ http://support.microsoft.com/default.aspx?scid=436213 65536 - 2(. & ..)ってとこか http://support.microsoft.com/kb/161982/en Linuxだと-o shortname= で挙動変えてSFN,LFNの場合も変わってくるんでない FAT16 クラスタ数 <= 65526 FAT32 65526 < クラスタ数 < 4177918 1つのクラスタに2つ以上のファイルは入れられないって制限もあるから これも関わってくるか？ ところでvfatって考え的には動的inodeじゃね？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/686
687: login:Penguin [sage] 2005/06/25(土) 21:11:55 ID:onicx32O users-jp(・∀・)ﾆﾔﾆﾔ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/687
688: login:Penguin [sage] 2005/06/26(日) 03:31:07 ID:ykvfdS2d >>686 ＞Windows では、長いファイル名、サブディレクトリ名、8.3 に短縮された ＞エイリアス毎に、それぞれディレクトリ エントリを使用します。 だから結局その半分。 昔1フォルダに3万強以上でファイルが作れなくなったことがあって「仕様と違う」 と思ってたことがあったのだが、これで理由がわかった。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/688
689: login:Penguin [sage] 2005/06/26(日) 03:55:13 ID:VMpc2wjm よーく考えろ。作れる数に制限ないとFATの容量(メタデータ)が決まらないだろう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/689
690: login:Penguin [sage] 2005/06/26(日) 09:50:02 ID:GiQyR/FG >>689 FAT の容量はパーティションの容量とクラスタサイズで決まったはず。 ファイル数等の制限とは直接は関係は無かったはず。 １つのクラスタに１つまでのファイルしか入らないので、 その意味でファイル数が制限されることはある。 メタデータは FAT とは別に存在して一応柔軟に生成できる。 但しオンラインデフラグでは移動や削除はできない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/690
691: login:Penguin [sage] 2005/06/26(日) 11:34:54 ID:GiQyR/FG my $cow = 1; while($cow < 65536*256){ my $we = ""; my $sd = $cow; while($sd > 0){ $we = "\\".($sd & 7).$we; $sd >>= 3; }; $we = "H:".$we; if(mkdir($we) == 0){ exit(); }; print($we."\t(".$cow.")\n"); #sleep(1); $cow++; }; こんなプログラム（Win用）で FAT32 上でフォルダ（ディレクトリ）を階層構造で作って見た。 DVD-RAM でテスト中、現在、８万以上のフォルダ生成に成功、速度低下も余りなし。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/691
692: login:Penguin [sage] 2005/06/26(日) 17:14:47 ID:oC8YKbwx FAT16 と FAT32 の違いって、なぁに？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/692
693: login:Penguin [sage] 2005/06/26(日) 17:47:34 ID:GiQyR/FG >>692 少し上に答えはあるぜ >>686 ついでに途中経過、４２万のフォルダを生成できた。 この調子だと容量を使い切るまで作れそうだ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/693
694: login:Penguin [sage] 2005/06/26(日) 18:12:14 ID:oC8YKbwx >>693 構造の違いについては記載されてないわけだが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/694
695: login:Penguin [sage] 2005/06/26(日) 18:21:53 ID:mVauA+98 >>688 長いファイル名が長いと、1つのエントリでは納まらないのでさらに減ります。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/695
696: login:Penguin [sage] 2005/06/26(日) 18:25:26 ID:oC8YKbwx /usr/src/linux/include/linux/msdos_fs.h にある構造体とかか。 msdos_dir_entry msdos_dir_slot Windows95 になったとき、それまでの MS-DOS ようのプログラムが、 msdos_dir_slot を適正に処理できなくて、うんこな状態だった話とか そんな昔話してもいい？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/696
697: login:Penguin [sage] 2005/06/26(日) 18:32:18 ID:i4XLxkmZ そういえば、FAT系って ・ルートディレクトリのエントリ数の制限(FAT32でルート移動可になって解消だっけ？) ・システム内ファイル数の制限(クラスタ数の制限だっけ？) があった気がするけど、 ファイル数の制限には、「サイズ０のファイル以外で」という条件があったはず。 つまり、サイズ０のファイル(ディレクトリエントリのみ)は 容量が許す限り、幾つでも作れたはず。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/697
698: login:Penguin [sage] 2005/06/26(日) 18:34:46 ID:oC8YKbwx つーことは、EOF_FAT を書くから消費されないということでつかね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/698
699: login:Penguin [sage] 2005/06/26(日) 20:29:30 ID:53gDFny3 メタデータを使わないファイルシステムって 代表的な奴は何になるのかな http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/699
700: login:Penguin [sage] 2005/06/27(月) 00:17:39 ID:XIAnMrHa >>686 にあるようなディレクトリごとのファイル数制限について。 ttp://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx ルートディレクトリのファイル数制限は FAT12・FAT16 の制限で一般に 512 まで だけど、フォーマット時に決められる様で 65535 まで増やせそうだ。 サブディレクトリや FAT32 のルートディレクトリのファイル数制限は FAT の仕様ではなく Win98 系の実装上の制限が原因の様だ。 Win2000 系においても互換性のためにあえて制限しているようだ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/700
701: login:Penguin [sage] 2005/06/27(月) 00:22:44 ID:NSUS6+Q8 マウントの概念がなかった時代に関しては、ルートディレクトリに たくさんファイルをおける必要はないもんなぁ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/701
702: login:Penguin [sage] 2005/06/27(月) 12:41:25 ID:pXBFKh0E >>701 FDの時代だ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/702
703: login:Penguin [sage] 2005/06/27(月) 12:48:58 ID:p4DBj9q6 >>701 今更ながらすげー納得した http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/703
704: login:Penguin [sage] 2005/06/27(月) 14:21:45 ID:Dj69fw9T >>702 1Dなら160kb http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/704
705: login:Penguin [sage] 2005/06/27(月) 20:39:32 ID:Zr371K4o 階層ディレクトリの無い時代にも同じ制限があって、困っちゃったわけだが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/705
706: login:Penguin [sage] 2005/06/27(月) 22:54:14 ID:XTzwjHSw 他のfsの歴史はちゃんと1.0公開とかあるのに 1997年6月23日 reiserfs のソースコードを web に置く ってのがﾜﾛﾀ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/706
707: login:Penguin [sage] 2005/06/28(火) 05:41:49 ID:VwXWpqIZ >>699 ファイルサイズもメタデータなので メタを持にないFSで代表的なのは まずはテープデバイスだろう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/707
708: login:Penguin [sage] 2005/06/28(火) 06:52:53 ID:Si6gc8X+ 漢直ユーザですか？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/708
709: login:Penguin [sage] 2005/07/09(土) 21:57:47 ID:Ubb0Ca9l wikihouse重杉 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/709
710: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/07/10(日) 00:38:42 ID:cUIiVWkd wikihouse重杉 ということで7/7 wiki.livedoor が出来たのでミラー作成 ttp://wiki.livedoor.jp/linuxfs ソースをコピーしただけだから若干表が崩れてます。 ＃livedoorは手動ミラーなので更新遅いかも。。 vfsをとりあえず、完成させてから ext2,nfs,reiserfsの説明を充実していきます。 vfs部分はgoogleで調べても載ってないものが多いから ソース調べて書いてるけど、間違いあったら指摘 よろしくお願いしますm(_ _)m いろいろ書きたい。。(*´Д`) kernel2.6.13のこととか脱線気味もたまにはあるけど 気長に完成目指してがんばるっすよ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/710
711: login:Penguin [sage] 2005/07/10(日) 00:50:22 ID:kqrF/M/5 >>710 乙。 > kernel2.6.13のこととか脱線気味もたまにはあるけど むしろそれが面白い。 雑誌だとコラムとかに面白いネタ転がってたりするし。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/711
712: login:Penguin [sage] 2005/07/10(日) 01:38:32 ID:ZmoKp9tD >>710 おまけのところ s/XIM/XIP/ ramdiskなんかに置いてある実行ファイルを そのまま実行してしまうという技でつ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/712
713: login:Penguin [sage] 2005/07/15(金) 20:17:59 ID:U9SD/WLG ttp://www-6.ibm.com/jp/developerworks/linux/050715/j_os-openafs.html OpenAFSって使ったことある方いますか? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/713
714: login:Penguin [sage] 2005/07/15(金) 23:55:01 ID:2mmQ3FNZ @it にて、 ttp://www.atmarkit.co.jp/flinux/rensai/linuxtips/763fsflag.html の、記事を読む。 今まで、「Linuxでデフラグは、いりません。」と、読んだ本に書いてあったので、 「どういう仕組なんだろう。」と、不思議に思いつつも信じていた。 のに。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/714
715: login:Penguin [sage] 2005/07/16(土) 00:29:55 ID:XZff9mlB フラグメント化した状態は示されても、 フラグメント化したディスクへのアクセスがどれくらいパフォーマンスを劣化させるかは示されていないのだが、 それでよいのか? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/715
716: login:Penguin [sage] 2005/07/16(土) 00:31:56 ID:TrDZO+rB なんか /bin/bash あたりがフラグメントしてるのを見て鬱になったぼくがきましたよ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/716
717: login:Penguin [sage] 2005/07/16(土) 00:40:12 ID:/wbHtX7A /bin/sh -> /bin/bash な環境なら確実にキャッシュに入ってるだろうし、 そうでなければ逆にまったく問題ないであろう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/717
718: login:Penguin [sage] 2005/07/16(土) 01:50:23 ID:OEvkVj9m >715 ttp://lc.linux.or.jp/lc2005/01.html http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/718
719: login:Penguin [sage] 2005/07/16(土) 03:07:26 ID:XZff9mlB >>718 それ中身を良く読むと、 ・ iozoneを複数個並列に動かすような、実環境でありえない方法で激しいフラグメント化を起こし ・ にも関わらず、CPU占有時間は変化せず(スループットは低下せず) ・ シングルスレッドのパフォーマンスの低下も1/2程度 となってて、結局のところ 「実環境でext3fsのフラグメント化の影響を心配する必要はありません」というデータに 見えるのは、私だけかな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/719
720: login:Penguin [sage] 2005/07/21(木) 23:07:52 ID:DRSMPsxh > うはっｗ俺Al Viroのpatchみてねーや リーナスあたり言ってそうだな http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/720
721: login:Penguin [sage] 2005/07/22(金) 12:38:12 ID:9zr4nTQB ext2で/から辿れなくなったファイルを救出しようと別領域から立ち上げて dd skip=1300447 ibs=4096 count=1 if=... でそのファイルがあるディレクトリらしき所を見付けました。 ところが、debugfs で cd <1300447> とやっても Ext2 inode is not a directory となります。 <>内に何をいれれば該当ディレクトリにcdできるのでしょうか e2fsck -n の結果は Block size=4096 (log=2) Fragment size=4096 (log=2) 1107584 inodes, 2212953 blocks 110647 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=2269118464 68 block groups 32768 blocks per group, 32768 fragments per group 16288 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 です。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/721
722: login:Penguin [sage] 2005/07/23(土) 07:47:53 ID:EqoQk/vO XFSをハードウェアのRAID上（3ware 9500Sシリーズ）で使用しています。 というか運用を始める前にいろいろ実験してます。 Filesystem タイプ サイズ 使用 残り 使用% マウント位置 /dev/sda1 xfs 466G 359G 108G 77% /work1 ハードウェアRAID上でディスク拡張（OCE）を実施して /dev/sda 自身のサイズが増えているのですが /dev/sda1 のパーティションサイズを拡張させなければ xfs_growfs できないことに気がつきました。 で、partedでなんとかなんものかと思ったのですが partedはXFSのりサイズに対応していないようで・・・。 ここで知恵を拝借したいのですが ・XFSを使用することを貫き通す場合、パーティション拡張するにはどうすればいいか？ （LVM上に乗っけることくらいしか思い浮かびませんでした） ・XFSにこだわらないとすれば、どのファイルシステムであれば パーティションサイズ拡張 → ファイルシステム拡張 ができるか 使い始める前にこのことに気がついてよかった・・・ 何か逃げ道知ってる方いましたらアドバイスお願いしますだ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/722
723: login:Penguin [sage] 2005/07/23(土) 08:46:20 ID:ojZigEI2 fdiskで削除、作り直し http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/723
724: login:Penguin [sage] 2005/07/23(土) 12:25:22 ID:oCGw48l0 LVMしかないだろ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/724
725: login:Penguin [sage] 2005/07/23(土) 13:57:25 ID:sJzcOMXy >>724 LVMの256GB制限って拡張されたのかな？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/725
726: login:Penguin [sage] 2005/07/23(土) 19:27:40 ID:p3zUyz4v どこの話？ PV？VG？LV？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/726
727: login:Penguin [sage] 2005/07/23(土) 21:45:10 ID:sJzcOMXy >>726 VGの話なんだけど、ちょっと誤解してたわ。 前に作った時に、エクステントサイズを変更するのを知らんで 256GB以上のVG作ろうとして失敗したもんでそこが制限かと思ってた。 調べてみたらエクステントサイズを拡張すれば、ペタまでいけるんだな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/727
728: login:Penguin [sage] 2005/07/24(日) 00:48:50 ID:gZFpPnFD http://nobumasa-web.hp.infoseek.co.jp/partition/parted/ libreiserfsをインストして partedでパーティションのリサイズやったことある方いますか？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/728
729: login:Penguin [sage] 2005/07/24(日) 13:51:20 ID:nR7scSGD ttp://www.suse.de/~agruen/acl/linux-acls/online/ JFS意外だな http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/729
730: login:Penguin [sage] 2005/07/24(日) 16:59:48 ID:4hOgkE3s >>728 qtpertedだったら二週間くらい前にやった。 小さくしたらちょいと壊れた… http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/730
731: 728 [sage] 2005/07/24(日) 19:09:27 ID:gZFpPnFD >730 qtperted使えばreiaserfsのパーティション拡張いけますか？ どんな感じのオペレーションしたか差し支えなければ。 KNOPPIXあたり使ったんでしょうか？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/731
732: 728 [sage] 2005/08/01(月) 02:15:47 ID:F13p05NA libreiserfsインストしても reiserfsのパーティション拡張できなくて血迷った発言してしまいましたが マシンリブートしたら普通に partedでreiserfsのパーティション拡張できました。 ご迷惑おかけしますた。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/732
733: 728 [sage] 2005/08/01(月) 02:19:30 ID:F13p05NA <チラシの裏> 結局いろいろ調べてみたけど データそのままでXFSのパーティション拡張する方法は見つけられませんでした。 xfs_growfsでファイルシステムの拡張は楽勝でできるのに・・・うぅ LVMは管理がややこしいのでちと避けたいの都合があるので とりあえずはパーティション拡張できるreiserfsで行くことにします。 </チラシの裏> http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/733
734: login:Penguin [sage] 2005/08/01(月) 08:40:08 ID:k6geJ+BY <チラシの裏> http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/734
735: login:Penguin [sage] 2005/08/02(火) 01:09:11 ID:rz2bf8eL 6TBの外付けRAIDは1TBづつ論理ボリュームが 切られているから、LVMなしではありえない。 そろそろ16TBの壁が見えてきた... http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/735
736: login:Penguin [sage] 2005/08/02(火) 01:09:49 ID:rz2bf8eL </チラシの裏> http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/736
737: login:Penguin [sage] 2005/08/02(火) 05:57:26 ID:nlMphKPH <トイレの壁> http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/737
738: login:Penguin [sage] 2005/08/02(火) 20:18:00 ID:7tHnst2D http://www.asahi-net.or.jp/~AD8Y-HYS/rakugaki.htm http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/738
739: login:Penguin [sage] 2005/08/05(金) 22:31:02 ID:WIqOo8zL 当たり前のような質問かもしれないのですが /dev/hda （300GB)上に dev/hda1 （200GB)を作成してデータを格納した後 fdiskで/dev/hda1 をいったん削除。 すぐに /dev/hda1 を300GBで作成しなおした場合 ファイルシステムが200GBのままだと思うのですが 中のデーターって読めない状態になっちゃうんですよね？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/739
740: login:Penguin [sage] 2005/08/05(金) 22:31:53 ID:WIqOo8zL </トイレの壁> 先に閉じ忘れちまったよ・・・ orz http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/740
741: login:Penguin [sage] 2005/08/05(金) 22:44:01 ID:KU4F9jr6 パーティションの開始位置が変わってなくて、終了位置がファイルシステムの末端より後ろならその作業をいくら繰り返そうが読める Win9xのfdiskだと読めなくなるがね http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/741
742: login:Penguin [sage] 2005/08/05(金) 23:26:12 ID:4Yibt62T Windowsのfdiskが、内部の情報までクリアしてしまうのは、↓こういうの http://cocoa.2ch.net/unix/kako/964/964868780.html を防ぐためだと思うよ。 端的にいうと、パーティションを小さくきりなおした時でも 内部(ファイルシステム)の持つサイズ等の情報が残っていると パーティションを越えた領域にまで読み書きが及んでしまう可能性があるから。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/742
743: login:Penguin [sage] 2005/08/06(土) 00:04:14 ID:3S3/1Uzt windowsは初心者が多いから、 「fdiskで見えなくしたから大丈夫」 と思う人が多いんだろう。だから、部分的に削除する必要がある。 Linuxの場合、いざというときのために削除しない。みんな分かってるしね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/743
744: login:Penguin [sage] 2005/08/07(日) 13:49:02 ID:Je5HZYTh <チラシの裏> ReiserDriverのrfsdfsd.regがExt2fsdのをそのまま持ってきててわらた </チラシの裏> http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/744
745: login:Penguin [sage] 2005/08/15(月) 23:08:32 ID:6QBzqfJz シーケンシャル書き込みをしたときに 書き込みが分断されにくいファイルシステムってどれになるんでしょうか？ Win機でキャプチャした動画をそのまま LinuxのSamba上に直接書き込みたいのですが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/745
746: login:Penguin [sage] 2005/08/16(火) 00:04:53 ID:00d/sAd6 mkfsした直後のファイルシステムならなんでも http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/746
747: login:Penguin [sage] 2005/08/16(火) 01:24:06 ID:QDWio2py tmpfsオススメ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/747
748: login:Penguin [sage] 2005/08/16(火) 05:31:23 ID:43STq93l tmpfs いいね http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/748
749: login:Penguin [sage] 2005/08/16(火) 12:42:30 ID:KdwkTm81 ramfsとは一味違うよな http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/749
750: login:Penguin [sage] 2005/08/16(火) 22:44:58 ID:4BururbB ext2でいいんじゃね？ 同時にいくつものファイルを扱ったり、小さい(ブロックサイズより)ファイルを大量に扱うのなら他を検討したほがよいと思うけど。 ストレージ容量やファイルサイズが馬鹿でかいときはxfs,jfsがいいって聞くけど、普通の動画ファイル鯖ぐらいならext2で十分かと。 まあジャーナリングぐらいつけておいたほうがよいかとは思うのでext3かな http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/750
751: login:Penguin [sage] 2005/08/18(木) 15:11:58 ID:k3U/nA8j <!-- UNIX USER 2004年9月号の51ページ に 「XFSは、小さなファイルをｉノードに格納する機能を持っており、 当然ながら格納したファイルのパフォーマンスは向上する。……」 って書いてあるんだけど、これ嘘じゃん！ だまされたーーー！！ --> http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/751
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 232 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.026s