仙石浩明の日記: Android 端末 (Nexus One) でアプリを SDカードの ext3 パーティションにインストールする (Apps 2 SD)
わずか 8個のアプリだけで 100MB 近く使っている。 200MB に収めようと思えば、 インストールするアプリを相当厳選する必要がある (100個程度で限界)。 さすがにこれでは使い物にならないということで、 アプリを SDカード上にインストールできるようにする仕掛け Apps 2 SD (A2SD) が提案されてきた。 A2SD には App2sd など、 いろんな実装があるが、 基本的には SDカードに ext3 (あるいは ext4) パーティションを切り、 /system/ext あたりにマウントして (実はこれが難しい, 後述)、 /data/app などからシンボリックリンクを張る。 つまり、こんな感じ: # cat /proc/mounts ... /dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0 /dev/block
blog of NiG:NTFS,ext3,ReiserFS等のファイル名の長さの話 - livedoor Blog（ブログ）
ファイル名の長さの制限 概要 NTFS(Windows) : 255文字(UTF-16) ext3(及びUNIXのファイルシステム一般) : 255バイト NTFSとHFS+ではファイル名にUTF-16を使用することが仕様で規定されているが、 Unix系のファイルシステムではファイル名の文字コードの規定はなく、NULL(0x00)と"/"(0x2f)を含まない任意のバイト列が使用できるようになっている。 ASCII文字だけ使うなら上記のどのファイルシステムでも同等だけど、マルチバイト文字を使うとext3の方が使える文字が少なくなる。 今のLinuxは文字コードにUTF-8を採用しているので、日本語は1文字3バイトとなり、255/3=85文字でファイル名のリミットとなる。 ext系 Filesystems HOWTOにてext2でも必要なら1012バイトまで拡張可能という記述があるが、その方
ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改
ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号（メモリアドレスみたいなもんだな）を調べて、そのブロック番号を指定してHDDやSSDにアクセスす
革命の日々！ ext3のデフォルトモードがwritebackに変わっちゃった件について
ext3のlatency問題に嫌気がさした、linus。 とうとうext3のデフォルトモードをorderedからwritebackに変えちゃった。サインが彼一人なのを見ても分かるように、誰にも相談せずに・・・ commit bbae8bcc49bc4d002221dab52c79a50a82e7cd1f Author: Linus Torvalds Date: Mon Apr 6 17:16:47 2009 -0700 ext3: make default data ordering mode configurable This makes the defautl ext3 data ordering mode (when no explicit ordering is set) configurable, so as to allow people to default to 'data
Linux チューニング - Ext3 のパフォーマンスを最大化させる
じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
高速化のつもりが停止させちまった - おやじまんのだめだこりゃ日記
