RAID総合スレッド No.4at LINUX
RAID総合スレッド No.4 - 暇つぶし2ch845:login:Penguin
09/07/23 02:17:58 vfIt/PSg
すごく初歩的な質問ですが
ディスク2本でRAIDより、ディスク4本でRAID1のほうが、読み書きは早いのでしょうか?

あと、ディスク4本でRAID5より、ディスク6本でRAID1のほうが、読み書きは早いのでしょうか?

ディスクが多いほうが分散されると思っています。

846:login:Penguin
09/07/23 02:26:16 3imsFcFC
0だから省略しました。

847:login:Penguin
09/07/23 09:52:32 qiDHBMgG
すごく初歩的な回答ですが
> ディスク2本でRAIDより、ディスク4本でRAID1のほうが、読み書きは早いのでしょうか?
CPU、I/F、HDDによって変わります。

> あと、ディスク4本でRAID5より、ディスク6本でRAID1のほうが、読み書きは早いのでしょうか?
CPU、I/F、HDDによって変わります。

> ディスクが多いほうが分散されると思っています。
何を分散するのかによって変わります。

> 0だから省略しました。
絶対にしてはいけません。

848:login:Penguin
09/07/23 11:22:28 8POTqhQB
>>847
アクセスパターンでも劇的に変わるね

849:login:Penguin
09/07/23 11:45:50 EFHH30yz
RAIDコントローラ、S/Wによっても変わるな。
RAID1でも読込を分散するかしないかで速度は変わる。


850:845
09/07/23 15:24:46 vfIt/PSg
HW/SW構成、アクセスパターンがまったく同じだとしたら、どうでしょう?


851:login:Penguin
09/07/23 15:33:54 uOV4F5O3
ディスクの本数から違うじゃねーか。

852:login:Penguin
09/07/23 15:44:50 8UkaR5pJ
>>850
全くオーバーヘッドの無い理想的な環境だった場合
HDD単体のスピードを1とすると

ディスク2本でRAID1 読2 書1
ディスク4本でRAID1 読4 書1
ディスク6本でRAID1 読6 書1
ディスク4本でRAID5 読4 書3

853:login:Penguin
09/07/23 15:47:22 gCdLHcID
>>850
> HW/SW構成、アクセスパターンがまったく同じだとしたら、どうでしょう?
その条件では、RAID0、RAID1、RAID5という違いを実現できません。
そもそもHW構成が違います。

854:login:Penguin
09/07/23 16:00:21 PPvVwfNO
>>852
RAID1でディスク増やすとリードが高速化するの?ほんと??

855:login:Penguin
09/07/23 16:24:10 gHbo44d1
少なくともうちのCentOSのS/Rでは変わらなかった。

856:login:Penguin
09/07/23 16:43:28 4TKdBEiW
>>854
ハードRAIDだとしてくれるのがある
例:URLリンク(support.dell.com)


857:login:Penguin
09/07/23 16:53:23 gHbo44d1
逆にライトは落ちていくのかな

858:login:Penguin
09/07/23 18:42:11 SaCC6aML
>>854
Linux md、FreeBSD gmirror、Windows ダイナミックディスク、SiliconImageはやってる

859:login:Penguin
09/07/23 23:40:40 3imsFcFC
gmirrorでround-robinとかsplitとか選べた気がするけど、誰かベンチとってないかなぁ

860:login:Penguin
09/07/24 00:10:53 xsQ+pNmK
>>853
アホだなw
本数はしゃーないだろ。

861:login:Penguin
09/07/24 00:52:50 Ym8Z1KGq
俺には元の質問の方がよほどアホに見えたけどなぁ。


862:login:Penguin
09/07/24 21:53:02 xsQ+pNmK
そもそもRAID1って、二本でしか組めないのでは?
三本とかあるの?

863:login:Penguin
09/07/24 22:01:32 E29uHdXM
3重でも4重でもお好きなように

864:login:Penguin
09/07/24 22:13:05 KIzvPTN3
じゃおれ10本でRAID1

865:login:Penguin
09/07/24 22:31:21 ydsNYj2x
それもありだなw
読み込みは早そうだ

866:login:Penguin
09/07/24 23:09:59 l+AVACqG
3本以上だとアレイのレベルで多数決方式のエラー検出ができるようになる。

2本以下だと、各ディスクからのバッドセクタ報告でしかエラー検出できない
(エラー訂正はバッドセクタ出てないセクタを使うだけなので2本でも可能)

867:login:Penguin
09/07/25 07:06:47 oTazRiOm
> 3本以上だとアレイのレベルで多数決方式のエラー検出ができるようになる。

マイノリティ・レポート><

868:login:Penguin
09/07/25 09:15:57 6KUfOyM2
>>830
LVMのスナップショットは,スナップショット取得後に
書き込むとすさまじくパフォーマンス落ちるから,
あれをバックアップする時にデータの整合性を保つために
一時的に使う以外の目的で勧めるのは犯罪だと思ってたが,
案外そうでもないのか?

869:login:Penguin
09/07/25 10:20:10 Fb3lMXfZ
>866
だから、具体的にそれをやってるのはどれよ?

zfsみたいにデータのエラーを検出したときに他から補間するというのならともかくさ、
せっかく読み込みを分散させて早くやろうとしても「多数決」なんてアホな方法では
台無しどころか却って遅くなるだけなんだが。


870:login:Penguin
09/07/25 11:49:37 qTghIUgl
つまるところ、こういう輩>>869がいるんで、先人たちはストライピングを
RAID0と呼ぶことを拒んだわけです。
先人たちの努力も虚しく「多数決」なんてアホな方法でストライピングは
RAID0になってしまいましたがねw


871:login:Penguin
09/07/25 12:27:18 Fb3lMXfZ
>870

あのな、>866の話はRAID1について語っているわけなんだが。
おまえ、RAID1でのReadの分散とRAID0のストライピングの区別も付いてないんだな。



872:login:Penguin
09/07/25 12:28:01 mjUm0ZPG
二本以上でRAID1組んで何が楽しいの?
仮に四本あるなら10にしちゃうぜー

873:login:Penguin
09/07/25 12:42:47 qTghIUgl
>>872
そりゃ確かだ。

>>871
もちろん>>866はRAID1の話だよ。
だが>>869
> せっかく読み込みを分散させて早くやろうとしても
と言い出したから、RAID1の話をしているのに「高速化」に話を向けようとするとは…
本当にRAIDの事わかってんのかなあ、と茶々入れてみただけ。

874:login:Penguin
09/07/25 12:51:31 I24lKVkH
読みの分散はRAID1ではありふれた手法。
それをRAID0と混同する方がありえんわ。


875:login:Penguin
09/07/25 13:09:28 qTghIUgl
>>874
いや、だからね。
分散させる意義として>>869のように「わずかでも遅くなるなら無意味!」って
言い出したから、RAIDに「なにより高速であることを求める」なら、ストライピングで
我慢しとけばいいのにって思っただけなのよ。

876:login:Penguin
09/07/25 13:22:39 I24lKVkH
>分散させる意義として>>869のように「わずかでも遅くなるなら無意味!」って
言い出したから、

無意味というのは"多数決でのエラー訂正"についてだろ。


877:login:Penguin
09/07/25 13:32:12 qTghIUgl
>>876
そう「遅くなる」から"多数決でのエラー訂正"は無意味だと言ってるよね?

878:login:Penguin
09/07/25 13:41:16 G+5AW0O+
エラー訂正は原理としてできるようになる、ってだけで、
必ずやってるわけでも、やらなきゃいけないわけでもない。

遅くなるのが嫌ならしなけりゃいい。信頼性がほしければやればいい。
それこそ設計思想次第だ。869はそのあたりの区別ついてないわな。

879:login:Penguin
09/07/25 14:25:01 Fb3lMXfZ
なにか席を外しているうちにアホな方向に話が進んでいる様だが、実際にそんなことしても
メリットがなく需要がないから製品が出てこないんだしねぇ。

そもそも多方向ミラーで、多数決では数が多いことは正しいことを保障しない。同じch上の
ディスクが同じように壊れていた場合、実は少ない方のデータが正しいなんてこともある。
だから信頼性を得るためにチェックサムを持たせる訳で、コントローラーがブロック単位に
そうやってたりする。その場合は普通に並列で読み出して、エラーを見つけたらその時は
もう一方のディスクから読み直す。zfsみたいにfsレベルまでカバーしているものだと、
ブロック単位ではなくファイルの単位でチェックして補償する。
いずれにしても、最初から全部のディスからおくなんて遅くなるだけでメリットがないから
普通はやらない。

>878
設計思想というより合理性の問題。


880:login:Penguin
09/07/25 14:35:58 qTghIUgl
よしよし、その調子でRAIDのことをもっとよ~く調べてみようね>>879

881:login:Penguin
09/07/25 14:52:05 Fb3lMXfZ
>880
その位にしておけ。
いくらなんでも子供の強がりにしか見えない。


882:login:Penguin
09/07/25 15:34:05 G+5AW0O+
>>879
>そもそも多方向ミラーで、多数決では数が多いことは正しいことを保障しない。同じch上の
>ディスクが同じように壊れていた場合、実は少ない方のデータが正しいなんてこともある。

チェックサムだけが壊れる場合を想定してみな?

多数決もチェックサムもECCもエラー検出と訂正のやり方が異なるだけで、信頼性を
得るという点では同じ。検出能力・訂正能力・コストの違いでしかないのに、
わざわざ区別して比較もなしに多数決に信頼性がないとか言ってしまうのは滑稽だねぇ。
まだまだ理解が甘いよ。

883:login:Penguin
09/07/26 10:27:34 zhSG5XX7
MAGIに信頼性がないって言ってるのか?このやろう

884:login:Penguin
09/07/27 01:03:07 +HNEeE0D
Software RAID した場合、ディスクの故障時はどうやって知るんでしょうか?
syslogの監視スクリプトを回すんですか?

885:login:Penguin
09/07/27 01:42:24 wX7L9b2s
つmdadmのモニタモード #ログ監視でもおけ

886:login:Penguin
09/07/27 13:31:30 iWpfkHHw
1TBのディスクを2つ買ってRAID1にして増設したいとおもっています。
LinuxのソフトRAIDです。

同じ機種でRAID1を組むと同時に壊れる可能性があって意味が薄れる
という意見がありますが、みなさんは2つの機種を組み合わせてますか?

今だとカカクコムの
1位のHDT721010SLA360 (1TB SATA300 7200)

2位のWD10EADS (1TB SATA300)
を組み合わせるとかするのでしょうか。

あるいは気にせず同じ機種2つでやってますか?




887:login:Penguin
09/07/27 13:41:38 yERWMvNo
気にしない

888:login:Penguin
09/07/27 13:44:31 B/WksD4T
1分1秒同時に壊れる可能性なんてほぼ0だろうし
気にしなくて良いかと。現に数年運用しているがそもそも
1台も壊れたことない。

889:login:Penguin
09/07/27 13:45:36 B/WksD4T
書き忘れ。壊れる前に容量が足りなくなってディスク交換
再インストールの方が多いなw

890:login:Penguin
09/07/27 15:03:54 VXnrrvY1
同じ機種の方がsmart情報を比較できたりするし個人的には好きだな。



891:886
09/07/27 16:11:01 iWpfkHHw
なるほどです。
気にしないで同じので行くことにします。
皆さんありがとうございました。


892:login:Penguin
09/07/27 22:52:57 wX7L9b2s
個人でだとHDDのファームバグとかにぶつかって移行した後(=切り戻しが
できなくなった後)で全HDDの交換・修理が必要とかなるとガクブルなので、
HDDは3台買って、2台は通常稼動させるRAID1で同じの、1台は別のメーカで
バックアップ用、とかしたほうがいいかも。

・・・と最近の海門事件で泣かされた俺が言ってみる。



893:login:Penguin
09/07/27 23:50:00 GBfB+zC9
ごちゃまぜのソフトRAIDでも、4台でRAID5やるとそれなりに速くなるな。

894:login:Penguin
09/07/27 23:53:45 o0m366If
個人的にはHDDはメーカーそろえるけどね。
メーカー、出荷時期が同じだからといって、同時に壊れるなんて、都市伝説じゃね?
不具合はのぞいた話ね。

895:login:Penguin
09/07/28 06:20:58 QlvXkbgA
>>894 まさにその不具合を避けるために、HDDのメーカは分けてる。
同一メーカ同一型番を同じ店で買うと同じロットの可能性が高いし、
かといって複数の店で買うのも面倒だ。

896:login:Penguin
09/07/28 09:37:30 hnSTLGA3
どうせ出来合いのサーバー買っても、同一のHDDでRAID組まれてる。

897:login:Penguin
09/07/28 14:10:19 BxFslx9I
出来合いの奴は、余程なメーカーでない限りエージング済みだがな…

898:login:Penguin
09/07/28 14:25:09 w0P0QAYm
エージング済みと書かれてれば高く売れるしな

899:886
09/07/28 14:25:17 d0ZK3SKF
ファームバグなんて10年に1度当たるか当たらないかですが、
当たったことのある人にしか痛みがわからないですよね。

やはり別メーカー2機種にしておく方がより安心ですね。
データが無くなるのは取り返しが付かないです。

逆に同じ機種にしたほうが良いことって「smart情報を比較できる」
以外にありますか?



900:login:Penguin
09/07/28 20:53:18 cfCC4a3c
3ware Escalade 9500S-8 を使って 300GB×4でRAID 5 約900GBのアレイを使っていたのだが、
手狭になって来たので 1.5TB×3で新たにRAID 5のアレイを作った。

で、旧アレイから新アレイへと cp -a * で丸ごとコピーしているんだが……
開始から約5時間でようやく100GB終わったところ。
つーことは、あと約700GB全部コピー終わるのは約35時間後…
う~む。トータルで丸二日近くかかる計算に。
大雑把に計算すると 100000MB/5h/60m/60s = 毎秒 5.5MB程度?
えらく遅いですよね。公式サイトには

> エスカレード 9500S ハードウェア RAID コントローラは実行値で400 MB/秒以上 RAID 5 読み取り、
> および100 MB/秒以上 RAID 5 書き込みという性能を 3% に満たない CPU 使用率で実現します

と書かれている。何がマズいんだろ。
同一カード内のアレイ間の移動だとこんなものなのでしょうか?

901:900
09/07/28 21:00:17 cfCC4a3c
書き忘れました。

使ってるドライバは kernel 2.6.16 に入ってる標準ドライバです。
メーカーが出してる最新版ドライバを使えば劇的に速くなる
てなことはあるのでしょうか?
(つまりLinux標準ドライバが劇的に遅いという事実はある?)

902: ◆Zsh/ladOX.
09/07/28 21:28:33 BB5WK76B
2.6.16使ってる鳥なんてあるのか。
ま、それは別として遅杉だな。

903:login:Penguin
09/07/28 22:11:17 LAvG5GBL
情弱Vineだろ

904:login:Penguin
09/07/28 22:50:34 I0tqAjdR
>>903
そんなに Vine が好きなのかw

905:login:Penguin
09/07/29 08:34:15 vy39CNTL
>>900
新アレイがビルド中で、すごく負荷がかかっているとか?

906:900
09/07/29 19:37:45 yXXhe56q
すんません。
なぜか新アレイの方のライトキャッシュがOFFになってました(汗)
ONにしたところ 30~35MB/s程度は出るようになりました。
# それでもメーカーの言う 100MB/sからは程遠いけど…
# やっぱり同一RAIDカード内の移動だから?

しかし、ライトキャッシュの有無でこんなに差がデカいとは知りませんでした。
いい実験になったw

907:login:Penguin
09/07/29 20:47:05 C5UGnnzw
>>906
同一カード内だからというより、PCIのカードだからじゃない?


908:907
09/07/29 21:13:37 C5UGnnzw
ごめん。64bit、66MHzに対応したカードみたいだから違うかも。


909:login:Penguin
09/07/29 21:50:48 xHRBI2w+
マザーがPCI-X使えなかったりして。

910:login:Penguin
09/07/31 10:15:23 opAatXfg
「なぜかライトキャッシュoff」なんじゃなくて、既存ボリュームの速度維持のためでない?
仕様として明記されていないかもしれないけど
複数のボリュームを構築することは推奨されていないのかもしれない。

mdドライバーがそういう挙動をするけど、RAID5新規構築では
リビルド処理として構築するほうが高速と言われている。

考えられる改善方法として、現在読み出ししか使わない古いボリュームを
ライトキャッシュoffにして、新しいボリュームのライトキャッシュを効率化。
それによって、リビルド中の書き込みが大幅に改善する可能性がある。


ちなみにうちはPCI-eのSATAカード一枚,md,dualcore2GHzでRAID10しているけど
2GBのファイルの同ディレクトリー別名コピーが49秒で終了する。
#vnc下のローカルファイルアクセスで計測

40MB/sでコピーできてる。/dev/nullに捨てると2GBを15秒で読み出せる。
WDグリーンの1TBx4だから、けっして速いHDDを使っているわけではない。

CPU負荷は低く、ほかのHDD上のファイルを複数エンコード中に、同様のコピーをすると
遅くなるどころか、高負荷下でクロックが倍増、書き込み速度向上で、36秒で終わる。

というか、これファイルサーバーとして設定がまずいことに今気づいた。

mdがもっと優先度高く動くようにしてやればいいのか?
それとも、cpufreqdの設定をもっとセンシティブにするか?


911:login:Penguin
09/07/31 23:09:37 Quc7GWrm
日本語勉強してまた来ましょう

912:login:Penguin
09/08/01 01:28:19 8oacFaY1
>>910
>/dev/nullに捨てると2GBを15秒で読み出せる。
おーい、現実世界に帰ってコーイ。

913:login:Penguin
09/08/09 11:50:53 OciFjnos
9650SE-8LPML-KIT
9650SE-8LPML
9650SE-8LPML-SGL

RAIDカードを買おうかと思うのだが、これらの違いは何?

914:login:Penguin
09/08/09 13:15:08 DOJSkVzQ
>>913

上2つは多分同じもの

9650SE-8LPML-SGLはMulti-lane break-outケーブルが省かれたパッケージ(single pack)
(マニュアルによるとバルク版もケーブルなし)

ケーブルはこんなの↓
URLリンク(www.oliospec.com)

普通の人は9650SE-8LPML-KITを買えばOK


915:login:Penguin
09/08/11 00:34:37 x2SvSkoB
>>912
実際問題、ソフトウェアRAIDの速度の相場はどの辺なの?
RAID5,10での読み出し書き込みとか…


916:login:Penguin
09/08/11 11:25:54 jYOBJKlM
そんなの使ってるハードウェア依存だろて。

917:login:Penguin
09/08/11 12:36:07 FYm7g77t
うちの環境でこのくらい
4台でmdのraid5
ディスクはバラバラで、一番遅いドライブが Barracuda 7200.10

$ dd if=/dev/zero of=test.zero bs=1024 count=10240000
10240000+0 記録始め
10240000+0 記録終わり
10485760000 バイト (10 GB) コピー終了, 104.255 s, 101 MB/s
$ dd if=test.zero of=/dev/null bs=1024 count=10240000
10240000+0 記録始め
10240000+0 記録終わり
10485760000 バイト (10 GB) コピー終了, 50.5835 s, 207 MB/s

書き込みが一番遅いドライブの2倍、読み込みが一番遅いドライブの3倍くらいといったところか。

918:login:Penguin
09/08/11 12:56:54 wRJhMhAx
CPUやSATA/IDEのコントローラ等々にも依存するのでは

919:login:Penguin
09/08/11 13:03:02 FYm7g77t
ボトルネックになるほど細くない限りは変わらんでしょ。
高負荷時は別だけど。

920:login:Penguin
09/08/14 09:11:56 JxCC0oUB
初歩的な質問ですみませんが、
RAID0組んでるHDDを電源とSATAを一度MBから抜いてまた同じ所に差し込んで元に戻すと前のデータ見れなくなったりしますか?
やってみれば分かる事だとは思いますが、バックアップするハードディスクも手持ちがなく、データが使えなくなると困るので、誰か教えてください。

921:login:Penguin
09/08/14 09:49:49 71s9m2K9
やってみれば分かる

922:login:Penguin
09/08/14 10:13:18 Bflix4To
データが使えなくなると困るのにRAID0ってありえないな。

923:login:Penguin
09/08/14 12:21:30 hqUEOy8y
確かにww
明らかに論理が矛盾してる

924:login:Penguin
09/08/14 12:40:01 Y5LWfhun
Unexpected Inconsistency - fsck manually! って感じですか

925:login:Penguin
09/08/14 13:14:00 BEe7EOWn
>バックアップするハードディスクも手持ちがなく
買えよw

926:login:Penguin
09/08/14 13:33:45 aeUBRV+u
>>920
やりたいことがいまいち不明。
何をしたいのかな?

まさか活線挿抜したいとかってことではないよね?

927:920
09/08/15 00:38:06 C0J0IAfI
そうですね、組み立てた時はとにかく速く動くようにしたかったんですが今思うと少し後悔してます…orz

ケースの取替えをしたいんですが…
誰か知ってる人いたら教えてもらえませんでしょうか?

928:login:Penguin
09/08/15 01:10:27 B5bx+teh
>>920
PCのコンセント抜いたらHDD上のデータが消えちまうようなPCって
どこかで聞いたことあるか?

929:920
09/08/15 01:30:45 C0J0IAfI
コンセント抜いてもCMOSはついててMBの電源?は切れてないですよね?
その状態でSATAを抜いても大丈夫なんでしょうか?

930:login:Penguin
09/08/15 01:49:58 J+6HndS1
自作PC板かハードウェア板逝け

931:login:Penguin
09/08/15 01:56:29 ViFUIe5U
>920
大丈夫だよ。
おまえのデータ全部消えちゃえ。

932:login:Penguin
09/08/15 02:26:28 ur3BVZX8
>>929
そういうレベルでLinuxのRAIDなんか使っちゃ駄目だよ。
コンセントを抜けば電源は完全に落ちる。
心配なら電源から出ているSATAのコネクタをテスターで測ってみ。
CMOSバッテリーはBIOS関連情報の保持で使うに過ぎない。

あとは>>930氏のいうようにスレを引っ越すのが吉。

933:login:Penguin
09/08/15 02:31:14 vp0q0mAw
FakeRAIDでWindowsを動かしている可能性

934:login:Penguin
09/08/15 17:56:51 wrXrviiq
>>929
活線挿抜でもしない限り大丈夫だよ。みんな何故この一言が言えないのか。
それ以上聞きたいならスレ移動どうぞ。

935:login:Penguin
09/08/15 17:57:36 wrXrviiq
あ、あと1本抜いたまま電源入れたりしても駄目だから注意ね。

936:login:Penguin
09/08/15 22:58:31 XWR81QLK
つか、そのレベルの知識しか持ってないヤツが
「ケースの取り替え」とか一体何考えてるんだ?
おとなしくメーカー製のPC使ってた方がいいと思うぞ。
自作したいなら、自力でモノを調べる技術をもちっと身につけんと。

937:login:Penguin
09/08/16 20:25:22 tg/bE0eZ
ちょっと知識を覚え始めた奴に限って偉そうに言う法則

938:login:Penguin
09/08/19 22:21:55 bRryD85g
mdadm の RAID 5 の grow(アレイの拡張)機能なんだけど、
TBクラスのドライブを使った場合どれくらい時間が掛かるものでしょう?
ぐぐってみても二桁GBクラスのものの例しか見つからなくて。
例えば 70GB×3個→4個 の拡張で 3時間とか。

容量に比例して時間が掛かると思っていいのかな。
1TBドライブとすると70GBの約14倍として 3×14=42時間?

誰かTBクラスのHDDでgrowやった経験のある方いませんか?

939:login:Penguin
09/08/19 22:26:54 bRryD85g
あ、>>628 に一例出てましたね。
CPU速度とかメモリの量にも依存するかな。

940:login:Penguin
09/08/19 22:31:01 VW8uXcc8
>921

941:login:Penguin
09/08/19 22:38:02 VTvYzTxQ
なにより、使用状態に依存するだろう。
動いてるサーバとかだと極端に遅くなる。

942:login:Penguin
09/08/20 10:37:29 C7HDGTrh
>>938
小さいサイズでやってみりゃいいのに。
原理から考えてボリュームサイズに比例、後は他タスクの負荷しかないから予測できる。

943:login:Penguin
09/08/20 11:26:06 qjr3+1CJ
>>942
・小さいサイズの事例はネット上に沢山ある
・大容量のときは違いがあるのか(容量に比例なのか?)が知りたい
というのが質問の主旨なのですが?

・基本的にサイズに比例
・使用中だと非常に遅くなる

ということで理解しました。
ありがとうございます。

944:login:Penguin
09/08/20 23:27:33 C7HDGTrh
>>943
ちゃうちゃう。回答の1行目は
比例するかどうか小さいサイズでやってみて傾向をつかむ
って話。言葉不足は謝る。
てっきり、重要なのは事例よりオーダーってあたりをきちんと
理解していると思っていた。


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch