【瓦記録】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 リロードすりゃ良かった
>>480
メディアキャッシュとLBAの対応表だろ
なおさらユーザーやOSからは通常知り得ない話だよ >>483
知りえない情報であってもそれはフォーマットのファイルテーブルと同様に
ファイルを書き込みを閉じた段階で書き込む必要がある、書き込み位置が決まっているのは当然の話 通常＝専用のデバイスドライバ入れない状態
でさ、ファームウェア側からは書き込み要求されたLBAしか知り得ない
対応の辻褄を合わせてキャッシュ吐き出すまでキープ
>>484
> 決まっているのは当然の話
決まってないよ
決まるとする根拠はファイルシステムのテーブル（メタデータ）だからでしょ
でもそれはファームから見るとメタとファイルの中身の区別はつけられないよ
あるのはLBAの違いだけ
ファーム側から見ると、ファイル単位で処理を切り替える理由って、OS側で通常のディスクキャッシュクリアの要求をしてベリファイかけるときくらいじゃないの？ 曖昧な「テーブル」という言葉を使ったせいで、
・fsレベルの書き込み
と
・ファームウェアレベルの書き込み
を混同してるね
メディアキャッシュやメディアキャッシュとLBAの対応はファームウェアからしか見えないし、fsの実データとメタデータの区別はOSからしか見えないよ >>485
決まってなけりゃメディアキャッシュ管理はできませんよ
どこにどこ用のデータが書いてあるかわかんないんだから
>ファーム側から見ると、ファイル単位で処理を切り替える理由って、OS側で通常のディスクキャッシュクリアの要求をしてベリファイかけるときくらいじゃないの？
CMR HDDであってもファイルの書き込み終了ごとにファイルテーブルを書き込まないとファイルテーブル書くまでの物は
瞬電などがあれば全部飛ぶ >>486
混同してるのはあなたでしょ
CMRの場合はフォーマットのファイルテーブルしかないし
SMRの場合は別にメディアキャッシュのファイルテーブルが存在する
SMRHDDがみる分にはntfsのファイルテーブルはデータでしかないしどこに置こうがメディアキャッシュのファイルテーブルがあればどうでもいいが
メディアキャッシュのファイルテーブルは位置が決まっていないとそれをもとに再書き込みや指示を実行できない 追記：
実用上は長い連続書き込み要求が来たら、直接要求されたLBAに「真のシーケンシャル書き込み※」が挟まり、短いようだとキャッシュ経由に戻る
ここはファームのチューニングの腕の見せ所
※連続したLBA書き込みが連続した磁性体への書き込みとなるかどうかはファーム内のさらに下のレベルで隠蔽されている
>>487
飛ばないよ
メディアキャッシュに残ってる >>488
一つ前の型の茂で既にCMRにもメディアキャッシュ積んでるよ
そもそもどうやってファームがfsを知り得るの？魔法？ >>489
メディアキャッシュに残っていてもどっからどこがどのデータかのデータがなければ
復元できない >>490
知る必要はない
SMRHDDがみる分にはntfsのファイルテーブルはデータでしかないしどこに置こうがメディアキャッシュのファイルテーブルがあればどうでもいい >>491
メディアキャッシュに関するメタデータはファームウェアが実データの先に書き出し後に消すだけだよ
これで飛ぶなら飛ぶタイミングを例示してくださいよ
>>492
「ファームからしたらfsの都合は関係ない」はこちらが最初からしている主張だよ
なんですり替えるの？ >>493
メディアキャッシュのある部分に書いてあるものは本来LBAXXXXXXからXXXXXXXに書くものというデータ（テーブル）が必要になる為
そのテーブルを書き込む前にデータだけ書き込んで止まったら飛ぶ
>「ファームからしたらfsの都合は関係ない」はこちらが最初からしている主張だよ
こっちもそれを否定していないしすり替えてもない >>494
データだけならファームは書き込み完了と判断しないよ
メタデータに齟齬がないかチェックするルーチンが入ってる
齟齬があったらメディアキャッシュの方を採用し、完了してない方は廃棄する
つまり飛ばない >>494
>> 「ファームからしたらfsの都合は関係ない」はこちらが最初からしている主張だよ
> こっちもそれを否定していないしすり替えてもない
すり替えたよ
ファイル単位で閉じたらメディアキャッシュもいじるって主張してた↓じゃん
>>466
> シーケンシャルライトが終わったりファイルを閉じたりするとファイルテーブル的なものをディスクに書くが >>495
だから複数のファイルを書き込むときに毎回テーブルを更新しないと
最後にテーブルをまとめて書こうとすると前回のテーブル更新以降の書き込み全て齟齬があることになって飛ぶじゃない アンカー間違えた
>>494
>> 「ファームからしたらfsの都合は関係ない」はこちらが最初からしている主張だよ
> こっちもそれを否定していないしすり替えてもない
すり替えたよ
ファイル単位で閉じたらメディアキャッシュもいじるって主張してた↓じゃん
>>467
> シーケンシャルライトが終わったりファイルを閉じたりするとファイルテーブル的なものをディスクに書くが
ディスクに書くがって↑これはなに？
fsレベルなら混同してるし
ファームレベルならすり替えてる
>>497
また混ぜる
fs？ファーム？ >>496
ファイルと書いたが
実際にはOS側が書き込み順を指定した場合ね >>497
これfsのテーブルだよね？
でも494のはファームウェアレベルだよ
混同してるね いい加減区別してくんないかなあ
>>499
これの説明をしてください
> シーケンシャルライトが終わったりファイルを閉じたりするとファイルテーブル的なものをディスクに書くが
「ファイルテーブル的なもの」って何？ メディアキャッシュだけに書き込まれたデータはOSからは読み出せないわけで
それはない物と同じこと メディアキャッシュのキャッシュヒット判定のセクタ代替情報がどこにあるかって話でしょう？
どこに有るかは知らないけれど少なくともディスク上に有ったら遅すぎて使い物にならんと思う。
いちいちヘッドシークしてメディアキャッシュ領域のセクタ代替情報を読みにいくとか非効率すぎ。
普通に考えたら専用メモリ、コスト考慮してDRAM内じゃないかと思うんだけどね。
なのでディスクに記録されるセクタ代替情報は参照されることが前提の配置である必要は薄く、
メモリ展開されるセクタ代替情報が構築できる程度に纏まってれば良いとする事ができる。
例えば各トラックの先頭セクタにそのトラックの各セクタの代替情報を纏める程度とか。
もちろんこれは勝手な推測 >>504
キャッシュはキャッシュなのでDRAMにあれば毎回読みに行く必要はないので非効率は関係ない
DRAMは電源落ちたらそれまでなので問題は解決しない >>502
・fsのテーブルとメディアキャッシュの対応テーブルを混同しないこと
・CMRにもメディアキャッシュ採用機種がある
せめてこの2つを頭に入れてから論じてください >>505
マジックなりCRCなりを併用すれば、不意に落ちても問題ない 上記はパーティションテーブルやRAIDのアレイ情報などで使われている枯れた技術 >>506
混同しているのはあなた
SMRの場合はキャッシュを使っている以上対応テーブルが必要になる
CMRでもメディアキャッシュを採用しているならSMRと同様の動きになる
>>507
落ちたらインデックス最新更新以降のデータは落ちるから問題大有り >>505
メディアキャシュのキャッシュヒット判定ってのはメディアキャシュ内にセクター代替されているかどうかの判定ってことね。
盛んに議論されているセクター代替情報の参照の事。
これがディスク上にあるのだとしたら非効率と言っている。 >>509
また変なこと言い出す
対応テーブルをどうしたいの？
>>509
ログとCRCとセットにしておけば、エラー箇所が割り出せる
あとはエラーのない操作をしたところまでキャッシュを廃棄しログを巻き戻せばいいだけ
fsのジャーナリングと同じ そもそもこの話題にはOSもファイルシステムも関係ない話だよね？
ホストからのセクタ指定とそのデータの指示において、
ドライブファームがどうやってメディアキャッシュを制御しているかという話であって。
ホストからはメディアキャッシュは見えないし、ドライブが勝手に代替処理をしている。
制御の手法としてはただのキャッシュ機構。
メディアキャッシュという特性を考慮してどう効率化するのかという話なだけ。 >>510
ディスクにあってそのキャッシュをDRAMに持ってそっちを使ってるから非効率ではない >>511
ログ書くならインデックス書くのと一緒だろｗｗ >>514
つうかfsのジャーナリングでピンとこないようでは話にならない たびたびログ書いてるならシーケンシャルライトになってない >>517
たびたびじゃないよ
マジックとかCRCはデータ自体とは比較にならないほど「小さい」 ジャーナルと同じことやってんならシーケンシャルライトじゃない
小さい小さくないの話は最初から出てなかった
たびたびじゃなければ最新の更新前は飛ぶね >>520
キャッシュと本来格納されるLBAとに瞬電などで不整合があっても簡単に廃棄できるの
>>487あたりから長々と見当違いの考察垂れ流しやがって >>520
同じことじゃないよ
メモリ持ってないとでも思ってたのか
例えば茂で騒動になったのはログ用のリングバッファメモリ より具体的な例を書くと
「a.txtとb.txtをメディアキャッシュ上の連続領域に書くときそれはシーケンシャルライトになるか」
といった話だよな
俺はならないと思うけど >>521
廃棄できても最新の更新前は飛ぶし問題ないことはない >>524
え？ログ用のはDRAMじゃないよ？
少量だからリングバッファで使いまわすんだし >>526
重要なのは揮発か不揮発では？
不揮発領域への書き込みならそこまでヘッドを移動しなくてはならんよね >>523
そのテキストファイルがそれぞれ1セクタを使うとして考えると、
「その後の使い方次第でシーケンシャルに書くこともできる」
だと思う。
要はメディアキャッシュ内の管理情報をデータと並べて書くかどうかという話でしょ？
通常の領域へのアクセスにおいても代替情報を参照しなければいけない以上は、
代替情報はディスク上にあるだけでは遅すぎてダメ。
より高速な媒体で実運用する必要がある。
つまりディスク上の代替情報自体は常時参照されるわけではない。
ならば手間をかけてデータと別に記録する必要はない。
とすることもできるでしょう。
内部解析でしないと答えは出てこないだろうし、きっとメーカーでも違う。 https://www.amazon.co.jp/gp/customer-reviews/R34F3SJL4S7KZS/ref=cm_cr_getr_d_rvw_ttl?ie=UTF8&;ASIN=B07911QK3X
5つ星のうち4.08TB*4 RAID6 で使用
2019年1月4日
容量: G : 8TBスタイル名: PC向け 3.5インチAmazonで購入
HGST の 4T がSMARTをはいたので ディスク交換か・・新たに作成か・・
10TBは割高で8TBを探したが・・あまりいい評価の製品は無かったので
最も安価なBarraCuda 8TBを4台購入
万が一に備えてRAID6で組むことに・・
もう一つ上のIronWolfを3台 RAID5 より安価に済みました
RAID6作成に 16時間以上
NFSで約 9TB のコピーに 82時間以上
比較には 25時間以上
raidチェックに 18時間以上かかりました
;(；ﾞﾟ'ωﾟ'); いいこと考えた
メディアキャッシュをメモリチップにしよう >>528
その場合メディアキャッシュにあるa.txtのデータをosがほしいと言った場合どうなるんだ？ DVD-Rのパケットライトみたいな意味でのシーケンシャルライトとか？
あるいはジャーナリングみたいな
ドライブが全て内部でLBA差し替えしちゃうからドライブ外からは分からない なんであれ隣接トラック以外のシークが発生しない書き込みが
シーケンシャルライトだと思うが >>531
メモリに展開されたセクタ代替情報をもとに
ドライブファームがメディアキャッシュ内の代替先から読んで返す >>534
そのメモリは揮発領域の事だよね？
そのセクタ代替情報はいつ不揮発領域に書かれるの？ メディアキャッシュに書きこむんだからその時に書いてる。
その書き込み場所がどこかという話でしょ？
メディアキャッシュ内の管理領域でもいいとは思うけれど、
ディスク上に記録されるまでの時間が最も危険な時間と考えると
そのトラックに一緒に書いても良いじゃんと。
纏めて管理領域に書きたいのは参照時に効率がいいからじゃないの？ メディアキャッシュなんてドライブファームからしかアクセスできないんだし、
内部でどんな管理してるかなんて勝手に想像するしかない。
管理領域に書いているという論を否定することは自分にはできないが、
書いているはずだという決めつけもまた同じ。
だから管理領域じゃない可能性もあると言っているだけ。
ランダムライト改善効果があるというメーカー主張がある。
それ以上でもそれ以下でもない。 >>536
そのトラックに一緒に書くというのは a.txt のデータと同じトラック内に
a.txt はここにあるという情報を書くということ？
そうなるとその a.txt がここにあるという情報はメディアキャッシュを総洗いしないと読めなくならない？ ドライブ起動したときに読めばいいんじゃない？
さすがに全読み込みだと起動に時間かかっちゃうだろうから、
トラック内でのまとめ位は有ったほうが良いと思うけれど。
後はメディアキャッシュ更新のたびに同時にメモリ上の参照情報も更新できる。
実際の数値まで考えてないけれど、流れとしては出来そうかなと。 >>539
トラック内でのまとめって何？
不揮発領域に書かれる何かのようだけど イメージとしては「管理領域」が各トラックごとに有ると思ってもらえれば。
トラック1周すれば書き込み完了するような。 >>541
そのトラック内でのまとめも例えば a.txt の書き込みについては
a.txt の書き込み完了時に書かれてる保証は無いわけだよね
つまり a.txt 書き込み後のトラック内でのまとめに書き込まれるまでの間に HDD の電源が落ちると
トラック内でのまとめから a.txt はロストすると思うんだけどその場合はどうなるの？
HDD起動後 a.txt は無かった事になる？ キャッシュの書き込みパケットごとにキャッシュされたデータが順次消えるとでも思ってるんだろうか
ふつうブロック単位で書き込み終わったら消えるだろ。何のためのキャッシュだ こういうのは「自分で作るとしたらどんな実装にするだろうか？」って妄想しながら考えると面白いし、理解も進む。 >>542
そのリスクはどこに管理領域があっても同じでしょ？
ホストからデータをもらって一番最初にディスク上に記録されるまではみな同じリスクだと思うけれど。
ディスク上の本来の場所への書き込みだったとしても、
シークしてあっちこっちに書いてる時間よりもメディアキャッシュに一気に書いたほうが結果的に早く、
データが喪失してしまう危険な時間が短いという状態になる。
いったい何の話をしてるのかわからなくなってきた
もともとは
・メディアキャッシュへの書き込みはディスク本来のエリアに対するランダムライトよりも早い。メーカー談。
・シーケンシャルになるから？
という話だったと思うんだけど。 >>542
回答としてちょっと訂正。
一周したら書き込み終わってればいいと思うよ。
a.txtの書き込みとb.txt書き込み、それらの代替セクタ情報、トラック1周している間に全部書けばいい。
書き換えだと喪失リスクがあるから2か所のトグル式でもいいと思うし。
その一周してる間の電源喪失リスクの話かと思って>>545を書いた。 >>542
もはやSMR/CMR、キャッシュ有り/無し
全然関係ない話になってない？ 書き換え数に制限の無い次世代不揮発性メモリがメディアキャッシュの役を負うと思ってたけど、
開発が間に合わなかったようだ >>545
管理情報の場所では無く更新タイミングが問題だと言っているんだよ
a.txt の管理情報の更新まで含めて a.txt の書き込み完了としないと
どこかで信頼度の低下を招く綻びが生じると私は思っている >>541
CM大の論文ではDMSMRのメディアキャッシュに某バンドセクタの更新情報が書き込まれると、
当該のバンドに関してダーティフラグを立てて要更新ステータス状態に旗上げするらしい。とか。
STLはトランザクション管理メカニズムの一種だろうね。
Consequently, when a write operation updates some part of a band, the STL writes
the update to the persistent cache, and the band becomes dirty.
An STL cleans a dirty band in the background or during idle times, by merging updates
for the band from the persistent cache with unmodified data from the band,
and writing back to the band, freeing space used by the updates in the persistent cache.
STLはSSDのFTLに相当するキャッシュ制御メカニズムのことね。
DM-SMR disks, on the other hand, implement a Shingle Translation Layer (STL)―similar to
the Flash Translation Layer (FTL) in SSDs―that manages data in firmware while exposing
the block interface to the host. >>546
トラック一周って外周だと3MB位になるけど
最低書き込みバイトが場合によっては 3MB 位になるって事？
100KB のファイル書くのにも3MB書く事になるけどそれだと全然早くならなくない？ >>549
HDDの内部動作を考える場合、一連のファイル操作は捨象して考えた方がいいような希ガスる >>546
よくわからないんだけど、メディアキャッシュ内のCMRって一周丸ごと書かないといけないの？ >>554
そんなわけは無いけど >>546 を実現するにあたって a.txt を書いたあと
トラック内のまとめを更新するまえに他のトラックにシークされていいの？
一周丸ごと書かないにしろ一周丸ごと回るまで他のトラックへのシークは防がないといけないんじゃないの？ >>550
SMRバンド側にフラグたててメディアキャッシュ見に行けって流れってことかな？
変換テーブルだのをはじめから作って処理するよりは実装楽そうだけど、
メディアキャッシュに収まったセクタへのアクセスはいったん該当SMRバンドまで見に行くってことか。
通電中の2回目以降のアクセスはメモリ上に代替アドレスマップが次第に構築されていくって感じかね。
そういう意味では代替情報はメディアキャッシュ内の管理領域というよりも、
該当SMRバンドまで無効フラグを建てに行くって感じか。
メディアキャッシュ内に全部収めることばかり頭に有ったわ。 >>555
さらによくわからないんだけど、
ヘッドアクチュエーターのシーク制御ってドライブファームがやってるんじゃないの？
勝手に何かほかの制御が割り込んで動かしちゃうものなの？ >>525
更新前は残る
DRAMじゃないんだし
>>547
そうだよね >>546
ユースケースで考えるとその方式にはもっと致命的な問題があったわ
外付けHDDとしてa.txtとb.txtを連続で保存して閉じるで書き込もうとして
b.txt書き込み中にHDDの電源を落ちたとする
CMRだと当然a.txtは管理情報まで書き込み完了してるので問題無い
b.txtはHDDの書き込は失敗したがエラーが返ってきたのでosのメモリ上には残ってるので割と問題無い
ただ >>546 の方式だと a.txt は書き込み成功を返したにも関わらず
管理情報が書き込まれず消失するんだよね
成功返しちゃったからosのメモリからも消えてるよ
b.txt に関してはエラーが返ってきてCMRと同じになるけど
やっぱファイル書き込み毎に管理情報も更新しなくちゃ駄目じゃね？ >>559
ファイルの書き込みごとに管理情報も〜という点に異論は無いけれど、
少なくともシーゲートは書き込み時の安全性をメディアキャッシュのメリットとして挙げているよ。
宣言文句なだけなのか何かしらの根拠が有るのかは知らないけれど。
で、対CMRは別にしてメディアキャッシュ内での書き込みの際に代替セクタ情報をどこに置くのがリスクが少ないのか？
という想定で考えた場合、そのトラックで終わる場合と別の管理領域までシークして書きに行く場合とで
どっちがリスク高い？
自分はトラック内だと思ったからの想像だったんだけど。 シーゲートの前モデルはCMRだけどメディアキャッシュ搭載だってのに
脳内のSMRを語るのもいいけど、現実の商品展開を見なよ 最近のSMRドライブのDRAMキャッシュが多めなのは、「メディアキャッシュの配置情報を全部DRAMキャッシュに乗せとく」ため、
みたいな理由もあるのかもね。
電源断でDRAMキャッシュが飛んだ状態で起動したら、最初にメディアキャッシュ内に書かれている配置情報を読み込みにいくとか。 >>561
実機はよく知らないが、4K物理セクタ移行期の512B LBAな論理セクタ対応のHDDとかだと
バンドサイズ4KのナンツーカミニSMRみたいな感じで元セクタデータを読み出し保存とか
あっても不思議ないかもねえ。今は論理セクタも4K移行済みのようだから両端の端数セクタの
マージ処理はまじ不要かもしれないけど。 >>556
妄想的に言えば、やっぱりテーブル参照でしょ。ヘッドシーク時間惜しいし。
メディアキャッシュの処理順はFIFOじゃないかなあ。FIFOのポインタを参照すれば
メディアキャッシュ上の空きエリアの先頭セクタを直に知ることになるし。 Ultrastarの7k8だかにはメディアキャシュと不揮発メモリ両方の搭載をアピールしてるんだね。
シーゲートMTCではホワイトペーパーでは言及しつつも実装例の話が出てこないし、
7k8の性能が気になるな。
WDはメディアキャシュと不揮発メモリはどう使い分けるんだろ。 >>561
脳内はお前な
DRAMじゃなくて残るのなら
NANDでも使ってるのか？
そんなチップがのってるソースが欲しいわ メディアキャッシュから書き戻す余裕も無いほどの負荷で、継続して読み書きし続けていたら、
SMRの性能低下は避けられそうもないですな。
逆にメディアキャッシュから書き戻せる程度の書き込み頻度や量なら、ランダム書き込み性能が向上したりするかもしれないと。 >>563
感覚的な概数に過ぎないけど、まだ今出てる機種の半分くらいは512e、すなわち512セクタをエミュレートしてる
残りの4割が4Kn、1割が512n
>>566
SRAM知らないとかねーわ >>568
SRAM wwww
ボタン電池とか入ってるのか？ >>560
なんだ、メディアキャッシュ上で複数ファイルをシーケンシャルライトするのは諦めたのか？
メディアキャッシュが安全なんてのは見当もつかないがソースはどこだ？ 民間療法を信奉する素人みたいな推測の域を出ないなあ いやいやお前ら目を覚ませ
メディアキャッシュなんてただのCMRの外周だぞ
メディアキャッシュでできる素晴らしいアルゴリズムがあるならCMRでも出来るだろうよ
ただ外周だから何もしなくても普通のCMRよりは性能は良いだろうよ 4Knなんてエンプラしか無いでしょ
コンシューマは512eしか見ないわ >>572
ま、HDDなんて単なる消耗品ですからねー
10年どころか3年保てば御の字でしょ。 ユーザー側が、メディアキャッシュすっ飛ばして本体部分に直書きさせろ
っていうコマンドを使えるようにすれば、問題のかなりの部分は解決するような気がする > SRAM wwww
> ボタン電池とか入ってるのか？ 変な引用しちまった
キャパシタ知らんとは思わなかったな >>572
だからCMRでメディアキャッシュ備えた機種はとっくに出てるって
その浅い脳のシワに刻んどけよ >>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 ■ このスレッドは過去ログ倉庫に格納されています
