ただつらつらと日記が書かれていくようです。

月: 2014年9月

HDDの故障率とか

Gigazineが「HDD約3万5000台を運用した実績からSeagate製品の圧倒的壊れっぷりが明らかに」って記事で紹介してたのが、Backblazeというオンラインストレージ屋さんのブログ。で、そのエントリーのタイトルは「Hard Drive Reliability Update – Sep 2014」。

HDDベンダーごとに故障率を出している、インフォグラフィックスが掲載されていた。…ご丁寧に、このタグで、このイメージをシェアできるよって書いてあったので、素直に貼るとこんな感じ。

Hard Drive Failure Rates by Model

いやー、Seagateさんの故障率の高さが目立つなぁという感じですが、Seagateといえば、ファームウェアのバグの問題が世間を賑わせたわけですが、その頃のモデル(Barracuda.11シリーズ)を使ってたら故障率は高いだろうと思って調べてみたら、SeagateのラインナップのBarracuda.12シリーズでも故障率高いから、うーんという感じ。

じゃぁ、BackblazeはSeagateだけ数多く使っててHGSTとか数が少なければ、故障率も正しくは出てこないよね!と思ったら、別の記事「What Hard Drive Should I Buy?」によれば、Backblazeで使っているHDDはSeagateとHitachiでそれぞれ12,000台ずつって感じだから、特にSeageteが数多いわけでも、HGSTが少ないわけでもないらしい。

で、この1月の記事では、こんな結論を出している。

We are focusing on 4TB drives for new pods. For these, our current favorite is the Seagate Desktop HDD.15 (ST4000DM000). We’ll have to keep an eye on them, though. Historically, Seagate drives have performed well at first, and then had higher failure rates later.

Our other favorite is the Western Digital 3TB Red (WD30EFRX).

まぁ、WesternDigitalのRedシリーズも使うけど、Seagateも長く使うと故障率上がるものの、最初は性能いいしなぁということらしい。RAID等で保護されていれば故障した際にはHDD交換すれば済むけど、堅牢だけど、遅いHDDを並べても性能がでるわけでもないしなぁ。

そんなHGSTの3.5インチHDD事業は東芝に買収されたことを思い出すと、Toshibaの故障率の推移はどうなっていくのか、ちょっと興味深い。今後もbackblazeにはHDDの故障レポートを公開して欲しいな、と。

Amazon Cloud Driveのデスクトップアプリがなくなった。

ちょうど一年前くらいに「Amazon Cloud Driveが直らない…」って記事を書いて、Amazon Cloud Driveのデスクトップアプリを改善して欲しいなぁ…なんてことを書いて、しばらくほったらかしにしてて、ふと新しいバージョン出てるかなと思って調べてみたら、こうなっていた。

Cloud Driveデスクトップアプリについて

Cloud DriveデスクトップアプリをAmazon.co.jpからインストールすることはできなくなりました。すでにコンピュータへインストールされている場合は、引き続き、ファイル、写真およびビデオをCloud Driveにアップロードできます。Cloud Driveデスクトップアプリをアンインストールすると、再度インストールすることはできません。ウェブサイト上のCloud Driveで、ファイル、写真およびビデオをアップロードしてください。

まぁ、ブラウザを使ってアップロードできるんだから、そっちでやってくれということか。まぁ、最近、Webサイトもリニューアルしたみたいだしな。Amazonとしては、Webサイトに訪問してもらって、うっかりついで買いしてもらった方がメリットあるだろうし。

というわけで、まともに動かなかったAmazon Cloud Driveのデスクトップアプリはアンインストールすることになるだろうなぁと…。

LGのG2のカメラ

ドコモがオンラインショップで叩き売りしてたLGのG2…ドコモの型番だとL-01Fなんだけど、このカメラアプリがちょっとなぁ。

まぁ、夏の暑い日にズボンのポケット入れたまま歩いて、ポケットから引っ張り出して写真を撮ろうとしたら「高熱のためカメラが起動できません」みたいなメッセージが出てきてカメラが使えないのは120歩譲って許す(とはいえ、XperiaでもGalaxyでも、似たようなことしてたはずだけど、そんなメッセージを見たこともなければ、壊れたこともないんだけど、まぁ、保護機能だから壊れてからじゃ遅いと言われりゃ、そのとおり)

普通にカメラアプリで写真を撮って、カメラアプリ内のサムネイルまで作成されるのに、後から、その写真を探しても記録されてないってのは何とかならないのかなぁ…。

ふと、可能性として思いついたのは…。高解像度で撮って、さっさとカメラアプリを閉じちゃうから、写真データをストレージに書き込んでるうちに、アプリが落ちちゃってるのかもしれないけど、もしそうなら、それってどうにかなんないのかな(汗)

…とりあえず、切り分けか…

追記:
やはり、カメラアプリからストレージに写真が記録されなくなってしまうと、再起動かけないと記録できる状態に戻らないような雰囲気。そして、再起動かけると、撮った後、ぱぱっとカメラアプリからホームに戻っても写真は記録されてた。もしかすると、メインメモリの空き状況の影響とかあるんだろうか。うーむ

LinodeとかDigitalOceanとか。

Linodeのリージョンが東京にあることに気づいて、早速、アカウント作ってインスタンスを立ててみた。

Linode TokyoはどうやらKDDIのデータセンターにあるらしく、同じくKDDI系のCloud Coreのインスタンスにping打ってみたら2msくらいで返ってきた(笑)あと、千葉のフレッツ網からのpingも20msくらいでネットワーク的にはかなり快適。DigitalOceanの西海岸だと太平洋越えで100ms超えるし、同じくDigitalOceanのシンガポールも100ms超えてたことを考えると意外と悪くないかも。メモリーは1GBしかないけど、ストレージはSSDだし。

しかしまぁ、AWSとかGoogleのクラウドが細かくネットワークセキュリティに配慮した仕組みを備えている一方、LinodeやDigitalOceanみたいな、安い系のVPS屋さんの「細かいことは気にしない」系のインスタンスは、何個もインスタンスたてると大変かも知れないけど、ちょっと1小インスタンス立ててWordPressでも運用してみようかなみたいな用途には悪くないかもしれない。とりあえずVPCみたいな仕組みは大掛かり過ぎるし、インスタンスでiptablesも使えるわけだし。

インスタンスが起動したら、とりあえずsshでルートログインさせる(rootパスワードを起動時にwebから入力させるのがLinodeで、DigitalOceanはメールで送られてくるんだったか)感じはなかなかドキドキしないでもないけど。

もし、初期ログインの後、ユーザーが適切に設定を変えられるのであれば、最初の導入時だけ雑なる感じになってしまうのもしょうがない…のかな(遠い目)

スマホ向けの動画をエンコードした。

今日、iPhone5で撮影したムービーファイルをもらったが、フルHDで撮影してあったので長さが90秒しかないにも関わらず、ファイルサイズが200MBあった(汗)その動画を撮影した人には、一緒に写っている人にシェアして欲しいと言われたけれど、このサイズで配布する必然性がほぼない(かつ、もらってもちょっと迷惑か)ような気がしたのでffmpegでサイズを小さくしてムービーのファイルサイズを縮小することにした。

とりあえず、普通にflvに変換してflowplayerを使ってWebで見られる状態にすることは出来たけど、PCでWebサイトを見てるときに動画を再生できるだけじゃなくて、スマホに動画をダウンロードしてネットワークに接続してなくても動画を再生したいというニーズがでてきて「スマホで見られる」mp4を作る必要がでてきたので試行錯誤してみた。

やったこと的には、mp4のプロファイルをbaselineにしてレベルを3.1にしてみた。一応、このレベルだと映像のビットレートがまぁまぁ高くても問題なさそうな気がするけど、ドコモのメディアプレーヤーではエラーが出て再生できなかった(汗)ので、ちょびちょびビットレートを下げていって、640×360って解像度の700k/sでエンコードしたら、ちょっと古いAndroidとかiPhone4でも再生できるmp4を作ることができた。

ちょうど、以下のようなコマンドでmp4を作った。

ffmpeg -i xxxxx.MOV -vcodec libx264 -ar 44100 -b:v 700k -aspect 16:9 -s 640×360 -profile:v baseline -level 3.1 xxxxxx.mp4