ついに、BIOSで起動出来ないHDD。
少し前に書いたSeagateの3TB HDDネタですが、海外サイトのReviewを見るとどうやら予想はだいぶ外したようで。
ということで、答え合わせしてまみしょ。
◇
1：600GB×5プラッタ ←外した
まさかSeagateが5枚プラッタを投入して来るとは予想外。
5枚プラッタを一般PC向にリリースするなんて酔狂をIBM～HGST以外がしてくれるとはね。
つまりこれ、現時点では未だ750GBプラッタを量産に乗せられないってことですな。
とはいえ600GBプラッタというのは現在のHDDラインナップを考えるとあまり取り回しの良くないモノなワケで、Seagateにしたって本命は取り回しの良い667GBプラッタの筈。これなら2TBをプラッタ3枚に出来るし、640GBな1プラッタ品も出来る。
そう考えると、当初「750GBプラッタを生産、選別落ちを667GBプラッタに、更に500GBプラッタに」のつもりが、実際には「667GBを生産、選別落ちを600GBプラッタに、更に500GBプラッタに」で精一杯だったのかも、なんて邪推してみたり。
◇
2：512Byte／Sector Emulation ←外した
一番びっくりしたのがコレ。ついに「素で2TBの壁に激突」するHDDが出てくるとは。
にしても、SATA側がNative BigSectorでなくSector Emulationで来たということは、既存システムとの接続を考えた場合はこちらの方がまだマシだとSeagateが判断したという風にも読めるワケで。
それってもしかして、そこらにはNatvie BigSectorだというだけでコケるBIOSがゴロゴロしているってことか？
◇
3：スタンドがNative BigSectorに変換 ←微妙に合っている？
この仕組み考えたの誰ですか、いやマジで。
まさかスタンドが変換してくるとは思わなかったよ。
でもこれ、要するにUSBでならNative BigSectorなHDDを繋いでも取り敢えず問題ないとSeagateが判断したということですな。一方、SATAの場合は前述の通り。
あと、スタンドでこういう変換されると、HDDやスタンドの使いまわしが出来ないよね・・・。微妙だ。
◇
・・・何だかね。
Over2TBを「普通に使う」には未だ時間がかかる、気がしましたとさ。
♯にしても、素で使ってて60度越えるHDDパッケージってのはさすがにどうかと。
さすがにコレは改善しないとマズいだろ、普通に考えて。
Tags: HDD
RDの予約をGmailから拾うために。
恐らく一番スマートでない方法を取ってしまったというメモ。
一言でまとめ：常時稼働している環境にPOP-SSL proxyを仕込む。
・・・さすがにあんまりなのでもう少しだけ補足。
一番メジャーなPOP-SSL proxyはstunnelではないかと。Windows版もありまっせ。
◇
ここからは普通に文章。
個人的な気分の問題かも知れないが、そもそもこのテの「ネット対応」「メール対応」を謳っている家電に、自分の普段使いのメールアドレスを設定するのはどうにも気が引ける。
一応この「気分の問題」にも根拠はあって、
１・パスワードを設定をするのがイヤ
一番の問題がコレ。
手元のRDの他、「ネット対応」「メール対応」を謳っている家電で、over SSL等の暗号化に対応しているというブツはお目にかかったことがない。
ということは、一度パスワードを設定したが最後、コレをナマで数十分毎に垂れ流すという世にも恐ろしい状況に。何ですかこの盗聴大歓迎設定。
更に、内部にパスワードを保持するということは。
故障した時・廃棄の時・中古売却の時、不注意もしくは諸事情により消去し忘れると、第三者にパスワード含めてアカウント情報がだだ漏れに。
それが普段使いのメールアドレスだったらこれ、ホントに致命的でっせ。
２・アドレス設定とかがイヤ
上に書いたアカウント情報だだ漏れの危険性も高いが、何より日常的にもっと大きなコトが。
家電の場合、メールサーバへの接続設定がはっきり言って面倒なことが多いんですわ。そんな面倒なコト何度もやってられますかい。
３・機械用メールと人間用メールがが混ざるのがイヤ
人間用は人間のルールで整理したい一方で、機械用メールは大抵そんなことお構いなしで、ヘタに触るとそれが原因で動かなくなったりする。
何で人間が機械に合わせなあかんのよ。
・・・とまあ、この3段ぐらいで。
以上の問題を解決するには「機械用のメールアドレスを作ればいい」という結論に達します、はい。
とはいえ追加でカネを払うのも何だかな～という方、フリーメールを探してみましょ。
一昔前と違って、タダでも今ではPOPが使えるモノも結構ありまっせ。
具体的にはGmailとGmail OEM系（livedoor mail等）、Windows Live Mail等。
まあどれかのアカウントを使ったとして、話を進めますね。
問題はこの後。
GmailやWindows Live MailではPOP over SSLが必須。まあパスワード垂れ流し防止ということで正しい対応だと思うが、こうなるとRDからは繋がらない。
さてどうする。
ここで登場するのが、手元で常時稼働しているサーバ。
このサーバ上でPOP-SSL proxy、要するに、生POPをSSLで中継してくれるプログラムを動かして、RD→手元サーバ→メールサーバという経路を確立する、と。
当方の場合、手元にほぼ常時稼働中のWindows機があるので、コレにstunnelを放り込んで設定しましたよ、と。
設定さえミスらなければ後は放っておけるので、特に難しいこともない。
＃このWindows機のFirewallに穴を開けるのを当初忘れていて、RDからのPOP接続が全然来ない・・・と首傾げまくったり（ぉ。
◇
・・・結局、なんだかんだで手元に常時稼働サーバが必要というのが、全くスマートでないのだが。
一応これで「普段使いとは別のメールアドレスを予約用に使う」という当初の目的は達しました、とさ。
Tags: Google Apps
ドライブの癖なのか、ドライバが悪いのか。
さて、円盤データ取り込み作業。
この作業中、何だかおかしなトラブルが発生したので思わずメモ。
ってか、こんな話聞いたこともなければ体験するのも初めてですよ。
◇
症状および再現方法：
１・媒体Aを入れる。
２・媒体Aを読み込み、中身をHDDにコピー。
３・DVDドライブのボタンを押して、媒体Aを取り出す。
４・媒体Bをセットし、DVDドライブのボタンを押してマウントする。
５・媒体Bを読み込む、中身をHDDにコピー。
普通に考えるて当たり前ですが、この「5」の時、媒体Bの中身がコピーされますよね。
・・・違うんですわ。
５・媒体Bを読み込む、中身をHDDにコピー。すると・・・
→何故か媒体Aの中身のコピーが始まる。が、コピー完成前にエラーが出る。
→コピーされたものは（当然？）中身が壊れている。
という、ものすごく迷惑且つ致命的なエラーが出ているんですわ。
発生要件：
現在のところ、Asusドライブ＋SATA（AHCI）接続の場合のみ。
同じドライブをUSBに変換して繋いだ場合、このヘンテコなトラブルは発生しない。
観察考察：
媒体読込キャッシュのハンドリングがおかしくないかこれは？
症状を見る限り「不整合なキャッシュが残ってしまっている」としか思えない。
対処方法：
媒体が無い状態で一度アクセスして、媒体マウントエラーを起こす。
こうするとキャッシュがクリアされるようで、次の媒体は正常に読み込む。
◇
・・・何コレ。
今のところAsus以外のドライブでは起こってないので、ファームの不具合か、Windows 7標準ドライバとの相性だと思うんだけどな。
まぁこのドライブ自体そこらから拾ってきたようなちょい古めのモノなので、Asusでも新しいモノなら当然こんなの治っているのだろうし、実はファームアップデートかければそれで解決する類の問題のような気もするが。
一応「こんなんありました」という話で。
Advanced Formant＋仮想マシンは要注意、かもしれない。
今更なんだけど、さ。
VMware Workstationネタ、続き。
というのは、つい先日。
調子に乗ってイロイロ置いていたらHDD空き容量が足りなくなってしまい、仕方ないのでWD20EARS・・・2TBでAdvanced FormantなHDDを導入、VHD置き場を移行したんですわ。
ところが、その後。何かVMの調子がおかしい。アクセスランプが盛大に光る割に、何かDisk I/Oが引っかかりまくる。OSだけでなく、アプリのパフォーマンスも明らかに落ちている。
結論。
Advanced FormatなHDDはVMware Workstationの仮想ディスク置き場には使わない方がいい。
上にどんなOSが乗るか分からない、というかイロイロ乗せられるのがメリットなVMware環境と、最新のOSでしかパフォーマンスの出せないAdvanced Formatの組み合わせは「やっぱり」ヤバい。
・・・まあ原理を考えれば当然なのだが。
実際使ってみたらかなりトンでもないことになりました、というお話でした、とさ。
＃つかここまで強烈に来るモンなのね。
ちょっと発熱が気になるが日立の7200rpmに交換すべきか？これは。
Tags: HDD, Virtualization
VMware WorkstationのDisk I/Oって、すごく・・・重いです・・・。
いやね、普通に重いとは思っていたんですよ。
でもね、まさかここまで重いとは思わなかったんですよ。
発端はDisk I/OとCPUを両方酷使する、某アプリをVMware Workstationで動かそうとしたこと。アプリの性質上VMware上で動かすと割と悲しいことになることは目に見えていたのだが・・・。
実際乗せてみたら、これが割とどころかもの凄～く悲惨なことになってしまったんですよ。
とはいえ、ここまで悲惨なことになるってのはきっと理由がある・・・ということであちこちつっついてみたんですが。
結論。VMware上の細切れ単位のランダムアクセスはもの凄～く重い。
ある程度の大きさのI/Oならばまだマシなものの、細切れアクセスに対してはもう「さすが仮想マシン」としか言いようがない。
で、これの解決方法は・・・無いよそんなの。
兎に角素のアクセスの重さは決定的なので、上位のOSなりアプリなりで吸収するしかない。といっても上モノのOSがWindows XPだったりするとOSレベルではもう手の出しようがないので、アプリ側でどうにかするしかない。
ということで、モノは試し。
アプリ側に手を入れて内部バッファをしこたま大きくして、且つDisk I/Oをある程度まとめて処理するようにしてみたところ。
何かものすごく調子よく動いているんですけど。
・・・と、ここまでやって気づいたのだが。
I/Oに足引っ張られるVMでこれだけ差が出たってことは、実環境でもI/O周りに手を入れたらパフォーマンスが上がる可能性があるってことでないのか、コレは。
んと・・・ちょっとやってみるかな・・・。
Tags: Virtualization
