きょうのつぶやき@digitune

きょうのつぶやき@digitune

最近、何かをググって調べ物をするとき、まずそのページが書かれた時刻を確認する癖が付いていることに気が付いた。で、2013年ならフツーに読むけど2012年以前だと読まないor「古い情報」と意識した上で読む。意識の上ではそんなにいろいろ変わっていると思ってたわけじゃないんだけど…。 (08:36 PlumeforAndroidから)

うほっ。流量制限付きの回線を使っている者としてとても楽しみだ。 “@jptechcrunch Google、モバイル版Chromeのデータ圧縮機能を公式にリリース―データ量を最大50%節減 http://dlvr.it/4jSNq0” (10:51 PlumeforAndroidから)

Androidのintent連携で、とあるアプリをデフォルトに設定(アプリ選択後「常時」ボタンを押す)した後にやっぱり別のアプリを使いたくなった時、これまで設定→アプリから「設定のリセット」をするしかないと思っていたんですが、個々のアプリ毎にデフォルトを外すことが出来るんですね。 (13:08 PlumeforAndroidから)

以前、僕が気にしていたSSDの自然揮発ですけど、近年のSSDのウェアレベリングアルゴリズムではデバイス全体に対してデータブロックのswap操作が行われるものが主流のようなので、日常的に通電されそれなりに書き換えが発生しているデバイスなら心配無用のようですね。 (13:36 webから)

もちろん全く読み書きせずに保存しているようなものはやっぱり５〜10年ほどで揮発しちゃうんでしょうけれども…。 (13:37 webから)

そうか、これまでウェアレベリングのアルゴリズムってどうなってるのかなーって思ってたけど、デバイス全体で平滑化するだけの素朴なものなら論理−物理ブロックのマッピングテーブルとカウンタ一つあれば実現可能なんですね。 (14:06 webから)

「次に書き込むべき物理ブロック」を指し示すカウンタを用意し、あるブロックへの書き込み要求があったら、先のカウンタの示すブロックの内容をこれから書き込もうとしているブロックが元あった物理ブロックへ退避後、カウンタの示すブロックへ書き込み、カウンタをインクリメント、でおしまい。 (14:11 webから)

カウンタが最後のブロックまで行ったらまた０に戻るようにしておく。まぁこの方法だと１回の書き込み要求で必ず２回の書き込み＋１回の読み込みが発生するから実際には性能を出すためにもっといろいろ手の込んだことをしているんだろうけど、とりあえず素朴な方法が分かっただけで収穫。 (14:14 webから)

あ、ちなみにマッピングテーブルの方も先の操作の中での変更に沿って適切に更新されることが前提です。この、物理−論理ブロックのマッピングテーブルの実装も実際のところはどうなっているのか謎だよなー。 (14:18 webから)

Android上でFacebookを、アプリではなくブラウザで見るようになってずいぶん経つけど、全く困ったことがない。 (20:06 PlumeforAndroidから)

この間、新宿駅を歩いていたらジブリ美術館の入場券が落ちていて。思わず拾い上げてどのシーンか確認しないでいるにはかなりの自制心が必要でした(^^;。(ジブリ美術館の入場券はジブリ映画のカットフィルムが挟まれているのです。) (20:17 PlumeforAndroidから)

昼間書いた素朴なウェアレベリングアルゴリズムの話、各ブロックに使用未使用フラグを持たせるだけで、書き込み先ブロックが未使用だった時に退避操作が不要になるので大幅に性能向上出来ますね。 (21:17 webから)

出荷時は全て未使用で、後は書き込まれると「使用」に変わるだけ、明示的にTRIMコマンドを打てば未使用に戻せる、というフラグを物理-論理ブロックマッピングテーブルに持たせるのですね。未使用ブロックからの読み出しには常にall 0が返るようにハードコードしちゃっても良いし。 (21:20 webから)