[次世代] ZFS Part2 [ﾌｧｲﾙｼｽﾃﾑ]

1 名前：名無しさん＠お腹いっぱい。 [2007/06/13(水) 15:28:31 ] 64ビットのチェックサム、128bitアドレッシング、RAID、ホットスペア、 スナップショット、ストレージプールなどの豊富な機能を備え、 次世代のファイルシステムとして期待されるZFSについて語るスレです。 ○前スレ [次世代] ZFS [ﾌｧｲﾙｼｽﾃﾑ] pc11.2ch.net/test/read.cgi/unix/1146631270/ ○関連スレ /**ファイルシステム総合スレ その7**/ pc11.2ch.net/test/read.cgi/linux/1173530292/ ○関連リンク Solaris ZFS ttp://www.sun.com/software/solaris/zfs.jsp OpenSolaris ttp://www.opensolaris.org/os/ ソース ttp://opensolaris.org/os/community/zfs/source/ 683 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/21(月) 15:29:26 ] 一時的に大きな更新が入ったからね。 ただ直ぐに改善するよ。 684 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/21(月) 19:47:40 ] >>682 もしかしてThe great CDDL file moveのことを言っているのなら それはファイルが移動しただけ。 >>683 ZFSのコードは年末からほとんど触れられていない。 大きな更新はないし改善もしない。 RELENG_7ではcacheのデフォルトを減らすのとzil_commit()をまめにするようになっただけ。 それも3ヶ月前の話。 もしそれ以上のことを知っているのなら教えて欲しい。 685 名前：名無しさん＠お腹いっぱい。 [2008/04/23(水) 04:40:09 ] FreeBSD で ZFS を iSCSI Target にしたいんだけど無理？ 686 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/23(水) 07:39:31 ] 無理ではないが無謀 687 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/23(水) 12:23:06 ] ただ頑張れ、と応援したい。 688 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/23(水) 13:47:24 ] オレが iZFS 開発するからもう少し待て。 689 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/23(水) 21:27:55 ] じゃあ待つ 690 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/25(金) 20:22:30 ] wiki.freebsd.org/ZFSTuningGuide メモリ1GBも何に使ってるんだ? 691 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/25(金) 21:29:45 ] まあ1Gぐらいならいいか…という気分になっていることは確か 692 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/26(土) 00:28:17 ] サーバ機の1GBはそれほど安くない。 マックス1GBというわけでもないようだし、 メモリ不足でpanicする危険があるようでは どんなに便利でも使えないではないか。 なぜ使えるメモリの範囲内でやりくりせんのだ。 693 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/26(土) 09:36:16 ] このレベルやってる人間がそんなことわからんわけないだろw 694 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/26(土) 10:17:23 ] ZFS使うSolarisにそんな要件はないので、 FreeBSDの実装はまだVMとのインタラクションが不十分なのではなかろうか。 695 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/26(土) 19:07:58 ] >>694 32bit CPUでsolarisを動かすと発生する。 これに対するsunの対応は「x64使え」なので、 32bit CPUでzfsを使うなら FreeBSD独自になんとかしなければならない。 696 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/26(土) 23:52:24 ] fsが管理するメモリなんてcacheが大半だから 足りなくなってもpanicする前にいくらでも逃げようがあるだろう。 と思う俺は素人? 64bit archとメモリ1GBが必要だというなら用意すればいいが、 過負荷時の生存性の低さも潜在してるように思うぞ。 697 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/27(日) 00:05:53 ] kerneltrap.org/FreeBSD/ZFS_Stability > "I guess what makes me mad about ZFS is that it's all-or-nothing; > either it works, or it crashes. It doesn't automatically recognize > limits and make adjustments or sacrifices when it reaches those > limits, it just crashes. 698 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/04/27(日) 02:59:25 ] >>696 うん素人。オレも素人だけどそれだけは自信あるww 699 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/01(木) 21:54:26 ] ReiserFSで有名な米国人プログラマー、殺人罪で有罪の評決 www.technobahn.com/news/2008/200804301057.html Reiser のスレないみたいだからここに投下しとくか… 700 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/01(木) 21:57:17 ] ここにはdump/restoreもないfile systemに興味のある人は皆無ですので、 Linux板あたりへどうぞ。 701 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 01:01:17 ] そうそう、あちらさんのファイルシステムって、dump/restoreがないのが 普通ってのがびっくりするよね。 まあpaxとかrsyncががんばってくれればいいと言われれば、ああそうですかって感じだけど。 702 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 02:03:41 ] 普通って、reiserだけじゃないの？ 703 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 02:06:00 ] しかし、ZFSの対象としている大容量なファイルシステムで、dump/restoreを使うか？ というジレンマもあるがな。 704 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 10:12:15 ] HDDの容量が増えたのなら HDDにdumpすればいいじゃない 705 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 12:03:14 ] JFSもext2もdumpなかったような 706 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 12:54:29 ] snapshotがないFSでdumpは不整合の元だしな 707 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 12:56:12 ] >>704 あほか。容量の問題じゃなくて所要時間の問題なんだよ。 708 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 13:29:16 ] 所要時間が長いのは前提で その環境で如何に完全なバックアップを成立させるかってことじゃないの? ZFS は send/receive がその役を担ってるんだよね? 709 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 14:10:18 ] うむ。snapshotあるんだからbackup windowは0だ。 オンラインではbackupする余裕がないのなら、それは資源の問題だ。 710 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 14:16:55 ] そうだよ。 別にLinuxの擁護するつもりはないけど、 dumpって絶対必要なのか？って訊かれれば、No、てことになるわな。 711 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 14:26:06 ] >>707 いやいや。メディア単価の問題でしょ? 世代管理と物理的に別箇所での保管。 712 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 14:56:21 ] >>711 何の話をしているんだ？それがdumpそのものと関係あるか？ 713 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 15:42:12 ] tarだのcpioだのpaxだのrsyncだので バックアップをとった *つもり* になるのは よくないことだとおもいます。 714 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 15:51:27 ] お前は何を言っているんだ 715 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 16:04:45 ] >>705 LinuxのJFSってdumpできないの？ AIXってmksysbとかbackupとかあったと思うけど あれはいわゆるdumpとは性格が違うんだっけ？ 716 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 16:08:38 ] >>715 それってオンラインでバックアップとれるんでしょ？ つうことは、dumpとは違うんじゃね？ 同じようなHP-UXのIgniteもバックアップ部分に関してはtarだし。 717 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 16:19:21 ] tarとかその他って、ハードリンクがちゃんと復元できるかどうか、とても不安にならない？ 今どきハードリンクなんて使わねえよなんていう人は氏んでください。 718 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 16:55:37 ] お前は何を言っているんだ 719 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 17:16:50 ] >>717 話飛びまくりだなwwwww cp -r で不安だから tar 使う、とか昔は言ったもんだ遠い目。 それを言うならホールだろ。 720 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 17:19:53 ] tarじゃあリンク復元完全にいかないことあるんだけど、知らない？ 721 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 17:20:28 ] どの tar? 722 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 17:36:54 ] 聞いたことないな。 むしろ心配すべきはシンボリックリンクのほうかとｗ これも変なオプション付けなきゃ（デフォルトのままで）問題ないし。 723 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 17:59:10 ] 「tarで問題ない」というのは 「僕はtarで問題に遭遇するほど場数は踏んでません」という意味だから、 永遠に話は噛み合わないと思うな。 tarも最近の実装なら問題ないと思うよ。検証してないしする気もないけど。 でもdump(zfs send)が使える状況なら、正確さと速度の両面でdumpが勝るのだから、 tarを使う理由はないだろう。 724 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 18:10:28 ] dumpとzfs sendじゃ仕組みが全然違うだろ。 一緒にするなよｗ 725 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 19:14:37 ] SunOS 4 付属の tar と GNU tar のこと知ってるやつならそう書くだろし。 かじっただけのマタ聞きに認定します今日は終了-- 726 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 19:22:43 ] そういや 386BSD の配布は cpio だった。...って脱線しすぎだなww 727 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/02(金) 22:54:50 ] solaris10でzfsのパフォーマンスをあげたいんだけど どこかいじれるばしょってありますか? 728 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/03(土) 01:01:00 ] メモリ増設 729 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/03(土) 01:47:07 ] plan9はhard linkなしだったな。 On the fly snapshotの実装が複雑になるから。 730 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/03(土) 02:14:56 ] >>726 386BSDじゃなくってもcpioってふつうによく使うじゃん。 731 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/03(土) 11:56:48 ] 「cpio 良く使う」で出身文化圏がわかる… のは言い過ぎか 732 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/03(土) 16:15:51 ] ほぼ確実に読めるって事でcpioフォーマットを使ってる事は結構あるん じゃないのかな。 商用バックアップソリューションのNetVaultもcpioフォーマットって 書いてあったと思うし。 安心感はあるかもね。 733 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/03(土) 19:06:01 ] cpioを毛嫌いすることもないよ 734 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/03(土) 20:35:47 ] cpioが嫌われる原因は、tarほど他OSとの互換性が高くないことその一点だろうな。 システムのバックアップとかに使うなら、tarより適している。 735 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/03(土) 21:56:33 ] cpioはoption名が覚えにくい。 Solarisのパッケージはcpio使ってたな。 736 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/03(土) 23:38:31 ] >>727 今どういう問題があって、どのような環境で、どういう風にパフォーマンスアップしたいのかしら？ 737 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/04(日) 00:13:59 ] cpio は互換性高いだろ。オプションが覚えにくいのと SysV 方面というイメージが敬遠要因と思うけど。 ま、昔の話だな。 738 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/04(日) 19:36:33 ] ところで disk fullになったときにrmでファイルを消せなくなる（かもしれない）というのはFAQですが そのときの対処方法は？ 739 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/05(月) 00:48:48 ] 知らないなあ… 740 名前：名無しさん＠お腹いっぱい。 [2008/05/05(月) 18:06:27 ] 各自が注意してdisk fullにしなければいいだけの話だろう。 あたかもFSの欠陥みたいに大騒ぎしてる奴は一体何が目的なんだ。 741 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/05(月) 18:12:52 ] なんだそれ 742 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/05(月) 18:16:21 ] disk fullに注意するのはいいが、なった時にファイルを消さないのは不具合でないの？ 743 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/05(月) 19:09:57 ] >>738 truncate 744 名前：743 mailto:sage [2008/05/05(月) 19:35:48 ] 発掘した ttp://lists.freebsd.org/pipermail/freebsd-current/2008-January/082615.html 745 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/06(火) 10:48:33 ] クライアントのIPを指定してsharenfsってどうしたらいいのでしょうか? 746 名前：名無しさん＠お腹いっぱい。 [2008/05/06(火) 18:29:55 ] ZFSと言うより、shareコマンドのオプションの問題。 747 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/07(水) 01:20:30 ] >>745 ホスト名にする or /255.255.255.255 をつける 748 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/07(水) 20:51:53 ] ZFS上でMySQL使ってる人っていないかな？ FreeBSD 7.0-RELEASE MySQL 5.0.51a で、試してるんだけど、INSERTが ufs2の上に置いたときと比べて、8倍くらい遅いんだ。 recordsizeは、16kにしてみてる(´･ω･`) 749 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/07(水) 23:28:19 ] 大切な情報を忘れていました。 ディスク3本をraidzで組んでいます。 これから、raidzせずに変わるか試してみるよ！ 750 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/08(木) 00:22:01 ] RAIDの原理的に考えれば、 RDBから書き込むブロックサイズをRAIDのトータルブロックサイズ にあわせないと、書き込みの度に読み出しが必要になって 遅くなるわな。 ディスク安いんだからRAID1がいいんじゃね。 751 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/08(木) 00:46:50 ] RAID（のレイヤ）にブロックなんてあるの？ 752 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/08(木) 02:37:55 ] >>746 すみません、shareコマンドの無いFreeBSDユーザは /etc/exports の形式をそのまま指定すれば良かったみたいです。 zfs set sharenfs='-maproot=root 192.168.0.1 192.168.0.10' tank/src 753 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/08(木) 14:35:10 ] www.solarisinternals.com/wiki/index.php/ZFS_for_Databases 結論から言えば、database用途にはzfsは向かない。中でもRAID-Zは相性最悪。 754 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/08(木) 16:00:27 ] 容量拡張的には魅力あるんじゃない? 速度的にはともかくとしても。 ヘマしたら悲惨だとは思うがw 755 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/08(木) 16:29:24 ] まあ、RAWつかえってことだわな。 756 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/08(木) 16:49:31 ] 追記型のPostgreSQLなら、zfsによるパフォーマンスの劣化は少ないかもね。 常にパフォーマンス優先というシチュエーションだけでもないので、 zfsが許容されるなら、recordsizeだけ気をつければいいのかも。 757 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/08(木) 17:16:35 ] >>753 やっぱそうかw まさしくRAID-Zで組んで何か遅いと思ったw 開発用DBの一つだから試験的に、と思ってたけどマシン性能に比べて遅いよなぁと思ってた・・・ 758 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/08(木) 17:44:57 ] >>753 DBの上にDB乗っけるようなものだからかなぁ 759 名前：名無しさん＠お腹いっぱい。 [2008/05/08(木) 23:56:54 ] RDBMS用途では、ファイルシステム云々より、write cacheの有無が 性能を左右するんじゃないかな。 と言う事で、そこそこのwrite cache積んでいるハードウェアRAID上に ZFS組めば、使えるのでは？ 760 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/09(金) 03:03:23 ] Oracleってzfsの上のソリューション紹介ってやってた記憶があるけど おすすめってわけじゃないのかなぁ 761 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/09(金) 09:05:35 ] >>759 正味 write back なとこに DB 置くの? チャレンジャーだな。 762 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/09(金) 09:46:09 ] >>761 大型ストレージは例外なくWrite Backですｗ 763 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/09(金) 09:59:13 ] ディスクキャッシュと言っても、大型ストレージのは普通SRAMだしね。 764 名前：BBWC mailto:sage [2008/05/09(金) 13:36:25 ] えぇぇぇぇぇ〜〜〜 765 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/09(金) 15:38:43 ] ここに書いてある通りの展開でワラタ blogs.sun.com/bonwick/entry/raid_z > Once again, expensive hardware offers a solution: a RAID array can > buffer partial-stripe writes in NVRAM while it's waiting for the > disk reads to complete, so the read latency is hidden from the > user. Of course, this only works until the NVRAM buffer fills up. No > problem, your storage vendor says! Just shell out even more cash for > more NVRAM. There's no problem your wallet can't solve. 766 名前：名無しさん＠お腹いっぱい。 [2008/05/10(土) 22:42:48 ] >>761 外付けのハードウェアRAID装置にDBを格納していない 事の方が驚く。 多くの「重要な」DBはHAクラスタで組んでいると思う。 HAクラスタには共有Diskが必要であり、SAN接続の ハードウェアRAID装置が主流だ。 こうしたハードウェアRAID装置にはwrite cacheが ついていると思うんだが、わざわざ殺しているのかい？ 767 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/11(日) 01:14:01 ] >>766 うん。殺してますよ。もちろん。 768 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/11(日) 01:28:27 ] >>767 HDD のライト・キャッシュは普通に殺すだろうけど、 RAID 装置のまでもか。 つか、バッテリ・バックアップがついてても、なのか？ 769 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/11(日) 01:34:37 ] バッテリつきならwrite (back) cache有効でも 目くじら立てることはないと思う。 770 名前：769 mailto:sage [2008/05/11(日) 01:37:22 ] >>769は >>768 への回答みたいになってるけど >>768 は見ずに書いてた。 ってか俺>>768〜>>769は6分以上あるのに, その間何やってたんだろう。記憶がない… 誰か俺に不揮発性記憶をくれ。 771 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/11(日) 01:40:33 ] バッテリ・バックアップのない RAID 装置なんかを 使ってる時点でダメだと思うんだが。ｗ 772 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/11(日) 01:47:20 ] ・DACボードにバックアップバッテリー ・外付けＵＰＳ装置 以上2つがあってWriteBackにしてもいいと思う まぁ、それでも飛ぶときはとぶがな 去年は1Ｔぐらい飛ぶのみてきたぜ！ 俺は保守する人なのでまぁ別にいいんだけど 773 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/11(日) 11:30:52 ] RAIDカードに信頼性がないんだよ。 一般論として、信頼性をあげるためにハードウェアレイヤを追加 しても、部品点数の増加(による信頼性低下)で大部分相殺されてしまう。 zfsのraid-zと同じ発想で、DBのRAIDによる冗長性確保は 特殊なハードウェアなしにRDBMS自身がやるのが一番望ましい。 774 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/11(日) 11:37:08 ] RAIDカードて。 それは冗談で言ってるのか？ 775 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/11(日) 12:00:16 ] >>773 SAN 接続の RAID ストレージの話だと思ってみてたんだが RAIDカードっているのか？ 776 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/11(日) 20:40:31 ] >>773 RAIDというとPromiseのゴミみたいなRAIDカードしか知らない人ですか 777 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/11(日) 22:23:33 ] NetAppやEMCだってコントローラのトラブルで死ぬときは 死ぬけどな 778 名前：名無しさん＠お腹いっぱい mailto:sage [2008/05/11(日) 22:35:44 ] それよりはドライブ吹っ飛んで泣きを見るよりは救いようがあるし 確率も高いから、ということでみんな使ってるんだよな 779 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/13(火) 15:18:11 ] MySQLって、ストレージエンジンを複数もてるから ZFSに最適化されたストレージエンジンをSun作ってくれないかな？ そしたら、MySQL＋Solarisが使いやすくなる。 780 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/13(火) 15:29:14 ] 当然しないとまずいわな 781 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/13(火) 16:26:18 ] というか、まだしていないのが不思議だ。 782 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/13(火) 16:56:19 ] 下手に肩入れしすぎると、Oracleと仲が悪くなって困るんじゃね？ 783 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/05/13(火) 17:26:16 ] そんなのPostgreSQLに手を出す前から仲悪いでしょ。 Oracle 1強という状況はSun的にも嬉しくないはず。

---

---

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

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