【瓦記録】SMRのHDD 4台目【ﾌﾟﾗｯﾀ枚数減】
■ このスレッドは過去ログ倉庫に格納されています
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
プラッタ枚数を減らし、価格が安くなるかわりにがランダム書き込みが致命的に遅くなる技術
Shingled Magnetic Recording (SMR)を採用した、通称瓦記録のHDDについて語りましょう
Shingled Magnetic Recording: Boosting Capacity and Lowering Costs
https://sata-io.org/developers/sata-ecosystem/shingled-magnetic-recording-boosting-capacity-and-lowering-costs
HDDの大容量化をけん引する瓦記録技術 - 東芝
https://www.toshiba.co.jp/tech/review/2015/08/70_08pdf/a08.pdf
SMR におけるビット信頼度への隣接ビットの影響 - 日本磁気学会
https://www.magnetics.jp/kouenkai/2015/doc/program/44ALL.pdf
スマートストレージ・スタックベースHBAおよびRAIDソリューションでのSMRドライブの使用
https://storage.microsemi.com/nr/pdfs/microsemi_adaptec_smr_whitepaper_ja.pdf
前スレ
【瓦記録】SMRのHDD 3台目【ﾌﾟﾗｯﾀ枚数減】
https://egg.5ch.net/test/read.cgi/jisaku/1541073336/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured >>580
検索しなよ
シーゲートの広告記事になってるから 結論
SMR方式のHDDであるST4000DM004を実際に検証してみて，たしかに従来の方式よりも確実に
遅いものの，問題のない速度であるという判断に至りました。もっとも，書き込みだけであって
読み込みであればまた別の話ですが。
ランダムアクセスはSSDに，大きなデータはHDDにという傾向は今後も一層強まるでしょうから，
容量的に有利なSMR方式のHDDを避けて通るのは難しくなっていくでしょう。あとはタイミングだけです。
というわけで熟慮に熟慮を重ねた結果，ST8000DM004を購入してバックアップ用のHDDとすることにしました。
第556回 SMR方式のHDDでも実用できるか検証する
https://gihyo.jp/admin/serial/01/ubuntu-recipe/556?page=2
------
まあ、こういうレポライターが此処の住人ではない。なんてことはナイのでしょうねえw おまえら朝からずっとやってんのかよ
怖すぎるわさすがに >>578
キャパシタってｗｗｗ
全然持たないじゃん
嘘ばっかり
>>579
それがあっても何の根拠にもならん ・windows入れてアップデートが遅くならないか
・windowsのテンポラリがSMRドライブ上にあるとき圧縮,展開は遅くならないか
・CMRに比べてデータの保持期間は同等か
・同時に幾つまで録画可能か
このあたりを検証してほしい ベンチマークはメーカが対策をたてているから性能差が潜在化している >>570
とりあえずメディアキャッシュのPR記事ね
https://weekly.ascii.jp/elem/000/000/415/415975/index-2.html
こういったメーカー主張に沿ってそれを実装を想像し
メディアキャッシュはランダムライトをシーケンシャルに処理できるから高速化する
という仮定の実現手段を具体的に想像してただけだよ。
自分はもともと>>528のように
シーケンシャル化の可能性を検討しているに過ぎない。
>>545にも書いてるじゃないの
>>572を見るとヘッドアームのシーク時間という概念が無いようだから
話が通じてないようなのはわかったけれど。 >>590
そんなんお前環すぎて確約出来るわけないやん
そんで、例えば(数字適当)4同時録画なら90％の確率で問題ない とか言われても困るでしょ？
SMRの問題は極端に低下する可能性があるって事でソレを許容できるかどうかってだけ >>590
同時録画数はwowowな24mbps 二放送まででしょ。普通は。 6MB/s。
3番組以上を同時録画できる家庭用録画機、液晶テレビはほとんど無いよね。
USB2.0規格で十分すぎるレベル。 >>592
DIGAの全録機は同時に６ｃｈの24時間フル録画＋１ｃｈ分の通常（予約）録画ができる
つまり７ｃｈ分のリアルタイム放送を24時間連続してHDDドライブ側の遅延なく書き込める必要がある
これはオマ環ではなく、DIGAの全録機をもつ全員がほぼ同じ環境である
impressの実証記事では、同時録画をたったの24時間行なっただけで。SMRは録画にも問題なし！と結論付けて、
あまりに杜撰な実験に、俺から顰蹙を買ってしまった >>592
HDD一台で4放送同時録画できる録画機とか液晶テレビってある？ 型番メーカー名ヨロ。 >>593
DIGAの似非全録機種BRGシリーズは６ｃｈを同時にDRで録画する >>597
地上波 地デジはmax 16mbps だから。 三放送で48mbps最大。 DIGAの似非全録機種BRGシリーズは6チューナ搭載で通常(予約)録画６ｃｈ分、もしくがチャンネル録画(8時間制限)６ｃｈ分を同時録画できる。
この機種の酷いところは、通常（予約）録画で圧縮モード（5倍録など）を設定していても、録画時には一旦DRで保存して、
アイドル時間にDR→指定圧縮モードへ変換を行なう。 つまりフルに使っていると24時間HDDはDIGAから書き込みをされていて、
もしHDDがSMRドライブならSMR内部処理に専念する時間がないのである >>597
最大三放送同時録画まで見たいですねえ
----
USBハードディスクに同時録画はできますか？（ディーガ）
チューナーを３個以上搭載しているディーガ
通常録画で同時に録画可能な番組数は、 最大３番組となります。
＊SUZ2060、SCZ2060は最大3番組まで同時録画ができますが、「4K放送（BS4K放送／110度CS4K放送）１番組＋ハイビジョン放送２番組」または「ハイビジョン放送３番組同時」の同時録画となります。
4K放送（BS4K放送／110度CS4K放送）を受信できるチューナーは１つですので、4K放送の複数同時録画はできません。
２チューナー搭載ディーガ
同時録画可能な番組数は、最大２番組となります。
１チューナー搭載ディーガ
録画しているときは録画用として使いますので、録画中の番組のみ視聴可能となります。
・USBハードディスクに複数の番組を同時録画するためには、USB3.0対応のUSBハードディスクをご使用ください。
http://jpn.faq.panasonic.com/app/answers/detail/a_id/41997/~/usbハードディスクに同時録画はできますか？（ディーガ） 全角野郎だぜ？
MbpsとMB/sの違いも知らんのだろう >>591
だから俺が >>442 で言った通り書き込み先がメディアキャッシュというプラッタの外周の一部に
限定されるからランダムライトでもシークが短く済むだけって事だろ
というかちゃんと記事で説明されてるんじゃねーか、ちゃんと読め >>602
って嘘。記事には直接はそう書いてはないな
記者自身「効率化を図ってるそうだ」って言ってるから良くわかってないんだろうな
メディアキャッシュに再配置場所を書く事なんてHDD利用者からはどうでも良い話なんで
多分記者も勘違いしていて実体は再配置場所を書く事によりメディアキャッシュという
狭い範囲にランダムライトを限定出来るからシーク時間を減らせて高速化されるんではないかと 総量によるけど、差分バックアップならともかくフルだったらあまり使いたくないなあ
>>582
rsync使ってみたのか
ウチはネットワーク転送用に1ファイル終わるたびにベリファイかけるオプションにしたら、死ぬほど遅くなってfsがそれより低レベルでおかしくなったんだよな……
>>588
根拠？
あんたが現実の商品を知らんかった事の根拠になってるよ >>603
その効率化の一環としてシーク減少による高速化に加えて
何かやってるのでは？シーケンシャル化してるのでは？という仮定の話だよ。
スレでもシーケンシャルでって考えてる人からのレスがそれなりに付いてるでしょ？
せっかく物理的な位置を無視して書けるんだもの。
一気に書いて効率アップをと考えても不思議じゃない。
それに乗れなかったようなのでレス付けてすまんかったね。 >>595
例・数字は適当って言ってるやん。揚げ足取りにもなってないよww
普通に読んだら「保証できるわけ・するわけ無いから回答するならこんな言い方になるけど、そんなの聞きたいか？ 」以上の意味はないって分かると思うが解んなかった？
ああ、最低xM迄落ちる可能性がありますって言い方なら出来るか。…数字忘れた…seagateで数M、WDは一桁位マシなんだっけ？
>>594
たったの24H…w
そんなんで良いと思うなら、削除しまくって汚れたら…とか考えなかったんじゃねww うちはガラポンTVに、2.5インチで3T SMRなHDDをつないで使っていたら、
何日間は動いているんだけど、最後は書き込みエラーになる。
何度か試したけど同じ結果。たぶん断片化が進むと厳しくなるんだろう。
仕方がないから2.5インチで1T CMRなHDDに交換したら何か月動かしても
問題は発生しない。
試したのは結構前なので、最新のSMR HDDだと違うのかもしれないけど。 >>605
メーカーにとってメディアキャッシュへの書き込みをシーケンシャル化する必要性が無いんだよ
何故ならそもそもSMRはCMRよりサイズで勝ってるわけでな
だからSMRを売る為にはCMR以上の読み書き性能であれさえすれば良いわけ
で、SMRの低性能を誤魔化す為に用意したメディアキャッシュにランダムライトで書いたら
CMR以上の性能が出せたので既に目標は達成されてるんだよ
メディアキャッシュのランダムライトがCMRより早くなる仕組みが良くわかって無い？
ってシーク云々言ってるからわかってるとは思うがシーク距離は相当少なくなるから十分でしょ >>591
というかこの記事のメディアキャッシュがデータの損失を防ぐこと
が全然データ損失を防げる理由になって無いと思うんだが
手前の高速化の理由もあわせて酷すぎない？ >>605
その効率化についてなんだが記事をよく読むと再配置にかかってないか？
なんかその記事相当おかしい気がするんだが PCSX2とかのエミュレータのROMをSMRのHDDに置くのはヤヴァイですかね？
読み込み用途だけなら大丈夫でしょうか？ 数十GB〜100GB前後のデータ大量に扱うのでうちの会社ではSMRは絶対無理
ここにいる最低な奴は、そういう用途を机上の空論などという奴
>>587、お前だよ
いい加減認めろや
SMRはオールラウンダーではない、用途によっては絶対に使ってはいけない >>612
なんで無理なんだ？メディアキャッシュ溢れるから？ >>608 >>610
あんたが相手の書き込み内容を理解してないだけに見える
（言ってることは同じだから）
>>615
溢れたら遅くなってその日の必要転送量に間に合わなくなるからだろうな 数十〜数百ギガを「ランダムに」扱う用途ってどんななんだろうな
シーケンシャル書き込みはメディアキャッシュを透過するとされてるし、ここで力説されるのはランダムなんだろうが
そういうのって複数ドライブに分散して逃がしたりできんものかね >>618
ファイル共有、あれもう終わった？w
まあ実際ランダムに使うというかゆっくりDLし続けたりすると
メディアキャッシュは一生はけないんだろうな >>617
言ってることが一緒って頭おかしいな
>605はメディアキャッシュに書き込む際にどうにかしてシーケンシャル化
>610はメディアキャッシュからSMRに書き込む際の再配置の際の場所を最適化して効率化
全然違う 確かになかなか確実にメディアキャッシュを溢れさせる用途が浮かばないな
アンチの人なんかあげてくれよw >>620
あっ、そうなんか
>>608 最終段のほのめかし、
> メディアキャッシュのランダムライトがCMRより早くなる仕組みが良くわかって無い？
はランダムライトのメディアキャッシュ上でのシーケンシャル化ではないのかー
じゃあどういう意味なんだろう？ >シーク距離は相当少なくなるから十分でしょ
で分からないのか？ シーケンシャルと言っても次のトラックに移動する時はシークが発生するしな。
普通は渦巻トラックじゃないし。 >>626
次のトラックはシークの分を考慮してセクタがズレてるよ
それで連続してアクセスできるようになってる それくらいみんな知ってるよ。 回転待ち時間が減らせる。 >>622
>>473 の言ってる通りなんだけど
ランダムライトについては特にシーク距離の短かさが影響しそうだよな
例えば1プラッタ1TBで10GBのメディアキャッシュを設置したCMRに
osからa.txtの書き換えを依頼した時を考えてみる
もしメディアキャッシュの無い通常のCMRでファイル管理情報が最外周にあって
a.txtが最内周にあった場合シーク距離が最大になるけど
このシーク距離を100とする
管理情報の位置等を工夫すれば100シークする事はまず無いだろうが
どう工夫しても期待値で2、30はシークする事になるだろう
一方でメディアキャッシュがある場合は1TB中の10GBなわけだから
メディアキャッシュは外周部分の1%にしか存在しない事になる
osからの書き込みはメディアキャッシュでしか受け付けないので
当然効率を考えて管理情報も外周に配置するとa.txtの書き込みのシーク距離は期待値で1以下になる
つまりCMRだろうがSMRだろうがメディアキャッシュを置けば
ランダム書き込み時のシーク距離が既存のCMRの数十分の一になる
実際osから見てどの程度の性能差になるかは知らないけどそれなりに差は出そうに思えないか？ >>629
件の人もメディアキャッシュはCMRでも意味があると納得してくれたようなので、そこは問題ないです
あとは管理領域書き終えなかったら飛ぶと力説してる件ですかね
ジャーナリングと同じで、書き終えたイベント以降は捨てるだけなんですが、納得してもらえるかどうか…… >>630
管理領域書き終えなかったら飛ぶってどれの事だ？ >>621
アンチじゃないけど、著作権切れの映画を大量にトレントで落とそうとしたら激重でずっとHDDがカリカリ言い出したから古いHDDを引っ張り出してそこに移したよ。 うぇ
海門瓦6Tだが
Get-FileHashでドライブ全体のハッシュを取得していたらファイルシステムが吹き飛んでやがる
やけに早く終わったなって思ったらエラー吐いてて、そのファイルを見てみるとあるはずのディレクトリが消えたわ
一緒にやってたWD6Tはエラー吐いてないので、やっぱりsmrは何かしら信頼性が落ちるのかも分からん >>630
どこまでイベントを書き終えたか書いておかないとどこまで書いたかわからないので
管理領域ないしはイベント履歴的なものが書いてある最終まで戻る SMRのドライブでメディアキャッシュを経由しない書き込みをするには
SMRバンドのサイズ以上の連続データであることが条件なのはわかるけれど、
メディアキャッシュ＋CMRの場合はどんな基準で割り振ってるんだろうな？
ホストから流し込まれたデータを俯瞰してみて
シーク距離が多そうな場所をメディアキャッシュにってくらいしか想像できないけれど。
ヘッドが内周にいる時にはメディアキャッシュのほうが遠いってこともあるだろうし。
そもそもメディアキャッシュの位置が外周とは限らないか。
ドライブ全体に対するシーク抑制という意味では中腹のほうがよさそうだし。 >>618
ギガをランダムって書くと違和感だけど、ギガの書き込みを複数並列でなら個人用途でもある人はあり普通に居るよ？
コンピュータ使うのって 定形化して自動化・仕事をやらせ、人は頭を使う事に集中するのが目的であり、今時のは「PC」レベルでも複数の処理をやらせてもこなしてくれるから、数十〜数百ギガまで行かんでも大きめの書き込み並列発生なんて俺でも結構ある。
PAD・スマホで事足りるコンテンツ消費ダケならそんな事無いだろうけど、PC使ってるって事はPADじゃ足りない事も想定するだよね？
618ダケじゃないけどさぁ…使い方は人によるってのを認ないような書き込みってなんなん？ >>632
お前の方式だと >>559 の場合に a.txt は消えないの？ >>636
ドライブ全体のシークというかメディアキャッシュから再配置する際のシーク時間を考える必要性ってある？ >>633
やっぱりメディアキャッシュを溢れさせる用途ってファイル共有位しかないんかね >>637
だよな
様々な用途を想定出来てないガキが草生やしながら
「例を挙げてみせろ」なんて片腹痛いわ >>637
ギガ書き込みを並列に書き込む場合CMRだとどうなるんだっけ？
かわりばんこに書くんだっけ？ >>637
根本的な話としてまっさらなバンドに書く場合に限りCMRの連続したセクタと同じように書けるよな
だからメディアキャッシュを使わない書き込みなんてのも出来るわけだからな
例えば1GBのファイルをバンドに直接書く場合1GB分の連続したバンドに書くんだろうけど
それは当然連続したセクタでもあり
CMRの連続したセクタと本質的に同じものと見なせるでしょ
だから別にギガの書き込みが並列だろうとバンドでもCMRのセクタと同じように書けると思うけど
1GB2個並列の場合1GBの連続したバンドを2箇所確保してから書くだけの話で
それはCMRで1GBの連続したセクタを2箇所確保してから書くのと変わらないでしょ >>637
だから、「結構ある」なら具体的に例示して欲しいと思うんだがなあ
無いのを示せってのは悪魔の証明要求ぞ？
議論の想定として、メディアキャッシュをフラッシュする暇もないほど大量のランダム書き込みが連続するってことにはなると思うが
個人でそんな大容量となると、動画（これは多分シーケンシャルで扱えるよな）以外だとそれこそファイル鯖くらいしか思いつかんし、ファイル鯖用としてSMRディスクが売られてる例あったっけ >>638
書き終えずに不具合が出れは、成功と返すことも無い
無いから元の場所にa.txtとやらは残るよ
ジャーナリングと同じって何度も書いてるやん
いいかげん理解しろよ >>644
> 悪魔の証明要求ぞ？
変なキャラ作っててキモいなｗ >>644
「普通は問題ない」って言いたいんだろ？
巨大PJのbuldでも、kernel等々のmakeでも、raw画像でも、4k8k動画でも、imgやDBのスナップショット取得でも、gitの更新・定期cloneでも、バックアップでも、torrentでも、TAT向上のためのキャッシュ更新系システムでも、readメインだけどbit化け対策のチェック系システムで
普通なんて人によるって言ってるダケなんだが、なんで理解できないの？
さっきも書いたがpadで事足りるようなコンテンツ消費以外にPCを有効活用しようと思ったらネタなんて人それぞれ色々あるんだよ。 >>644
おっとカッカして読み飛ばしてた。動画とファイルサーバ だけ？
なるほどww SMRドライブの動作の推測から考えて、
・連続したデータをSMRバンドサイズごとに区切れた分以外はみんなメディアキャッシュ行き
・ドライブファームがシーケンシャルとして拾ってくれなければメディアキャッシュ行き
こうなるよね？
ドライブファームは送り込まれたデータからしか判断できないことになるし、
DRAMバッファにため込まれた範囲でしかシーケンシャルの判定ができないはず。
結果的にどんな大きなファイルになるんだとしても、
OSがファイルサイズから書き込みセクターを調整したとしても、
データがDRAMバッファに収まる範囲で連続してこなければシーケンシャル扱いはされないはず。
こうなると思うんだけど、違うかな？
データストリームAとBとして並列で書き込んだ場合を想定すると、
DRAMバッファ内にはAとBのデータが混ぜこぜになっていて、
ドライブファームがそれぞれのデータをSMRバンドを埋めるに足る量だけ
連続データとして見つけることができればSMRバンドに直接書きに行けて、
見つけられなければメディアキャッシュに格納されてしまう。
DRAMバッファが大きいほどシーケンシャルに書きに行ける率が上がる。
となるのかな。 spotify使うとメディアキャッシュ溢れそうだぞw 流石にもう直ってるのかね
ttps://gigazine.net/news/20161111-spotify-write-junk-data/ あ、SMRバンドごとの先頭に該当するセクタの書き込みからバンドサイズ分が連続しないとだめなのか？ >>650
じゃあCMRの場合はどうなんだ？
>>643 にも書いたがバンドだって結局連続したセクタの一種でしょ？
CMRだってシーケンシャルライトの時は連続したセクタを確保して書くわけで
シーケンシャルライト時はSMRは連続したバンドを確保して書く
CMRは連続したセクタを確保して書く
バンドは連続したセクタの一種なので結局差異は殆ど無いと思うけど？ >>650
嘘。言ってる意味がわかった。サイズ未定のものを書く場合か。確かにSMRは苦手そうだな サイズ未定を書くといえばテレビ録画だよな
あれ結局どうなの？具体的にパフォーマンスの限界を示したメーカーとかないの？ >>654
１個のバンドの中に複数のセクタがあり、ドライブ外部からはバンドが全く見えずに
セクタしか見えない状況でPC側がアドレス指定して書き込み命令を出すわけだから
PC側にとっては未使用セクタへのシーケンシャルライトのつもりでも
「未使用セクタ」と「使用済セクタ」を含むバンドへの書き込みは
ドライブ内部で「使用済セクタ」部分のデータをリードしてコピー保存しておいてから
バンドを書き換えるというシーケンシャルとは呼べないアクセスになるんじゃ？ >>655
録画用途だと大したストリーム数は維持できなさそう、てのは前から言われてたよ 長期間このスレを読んでいるとSMRを実際に使ってこういう理由でダメだったという書込は全スルーしてます。
とにかく、信用できない、サンプル数が少ないとか言って、なんとかSMRは汎用性があってメディアキャッシュ最高！っていう流れにしたがりますw >>658
つまりCMRでのシーケンシャルライトではosがHDDのセクタ一個一個洗って
シーケンシャルに空いてる領域見つけてそのセクタ一つ一つに対して書き込み指示をHDDに出してるって事？
俺はそんな面倒な風にはなっておらずHDDに対してのシーケンシャルライトの指示は
パスとデータとサイズを渡すだけで良くなってると思うけど >>659
HDD内のファイル1個更新する毎に全然別の場所にある
不揮発領域にあるジャーナルファイルの更新も必要なわけでしょ
全然シーケンシャルライトにならない気がするけど？ >>652
resそんだけかい。急にアンカーもやめて…見逃す所やったやろが
お望みの例は一杯書いておいたから、個別事例が重要だと思うなら全部論破しといてね。まぁマジメに考えたら他にも一杯あるんだろうが
こっちの論は単に「普通なんて人による」ってダケ。PC特にSMRのような仕様だと、おま環や使い方への依存がキツイいから「普通は問題ない」って言うのは物凄く難しい os側に実装されたファイルシステムを理解して処理出来るドライブ
実装が想像つかない >>666
そうだな。だから普通はファイルシステムはHDD自身に定義されていると思うが
そうなってない特殊なHDDに遭遇したのか？ そんな認識だからドライブ内のデータ処理の話にファイルを連呼してたんだな。 >>668
なるほど。例えばNTFSでフォーマットしてるのはosか
でもメディアキャッシュなんて異端なものが入ってる以上旧来のNTFSの書き込みなんて出来るわけもないから
多かれ少なかれHDD内で改変、エミュレート的な事をしてるんだろうな >>664
ジャーナリングはログの使い方に関して似ているから持ち出したんだよ
ジャーナリングはファイルシステム上で、ライトキャッシュ関連のイベント、物理的には磁性体上
イベントログはデバイス上の不揮発性メモリ
これ絡みで約十年前のロック騒動知らない？
両者はレイヤが違う
いい加減覚えてくんないかな〜 ファイルを扱えるってことは情報機器ではものすごく便利で大切で無くてはならないものだけど、
なぜ"ファイル"って形になって存在してるか、意識してる人は少ないだろーなぁ。
そこいらへんのビットの塊があーだこーだして、人が使うときには"画像ファイル"やら"テキストファイル"
やらに見えてて、使う人の要望に応じて使える事実。
先人たちの様々な積み重ねが、何十年も経て今の形になってることに感謝しなきゃ。 >>671
>イベントログはデバイス上の不揮発性メモリ
これのソース出して
ディスクに書いてたものをこういうものにするならいづれにしても追加の部品が必要になり
コストアップになる もともとはファーム格納してあった不揮発メモリの一部じゃない？
今はファームはディスクからRAMに展開のようだけど。
フラッシュメモリより前の時代から有る機構だろうからEEPROMとかの >>671
レイヤがどうであろうがa.txtとb.txtを不揮発領域に書く間に
他の不揮発領域を読んだり書いたりしたらシークが発生して
シーケンシャルライトでは無くなると思うけど
そんなことが出来るのか？ 今の時代的に言えばSoCに不揮発なメモリをちょっと積んでてもおかしくないな。
ファームロックの時の修復の仕方から考えても、ジャーナル領域はディスク上には無いんじゃないかな。
基板とディスク側の接続を切り離した状態で基板起動してクリアしてたみたいだし >>671
ああ、不揮発メモリを追加で用意するのか！？
いや >>608 に書いた通りメーカーにはSMRのランダムライトを早くするモチベは無く
SMRは安さが売りだからそんな事にコストはかけ無いと思うけど ちょっと混乱しそうだから修正
ジャーナル領域→ロックの原因となったログ領域
ログが320個の状態で電源落ちると次回起動時にロックする不具合だったよね。確か。 >>678
それが何故不揮発メモリだから起きたのかっていうのはわからんが ■ このスレッドは過去ログ倉庫に格納されています
