SambaとZFSで大量のファイルを扱う時はcase-sensitiveを最適化する
ことの発端は、数万個のファイルがあるフォルダをSambaのファイルサーバにコピーすると、速度が10kB/s前後まで低下する現象に見舞われた。速度はコピーが進むごとに低下し、比例してsmbdのCPU占有率が上がるというのが特徴。サーバ上で直接コピーすると何の問題もない。 調査を進めると、Sambaはファイル名の重複チェックのため、ファイル作成時に作成先フォルダ内の全ファイル名を検査することが分かった。この時に行われる、ファイル名の大文字／小文字変換と比較処理がボトルネックとなっているようだ。Windowsでは歴史的にファイル名の大文字／小文字を区別しない1)が、UNIX系ではOS／ファイルシステム共に大文字／小文字を区別することが多い。このWindowsとUNIXの違いをSambaで吸収してやる必要があるわけだ。 プロファイルしたわけでもソースコードを見たわけでもないので確証はないが、Sam
Windows 10の回復パーティションを新しく作る
コマンドプロンプトを管理者として実行し、diskpartを起動する。 以下のコマンドで回復パーティションを作る。select disk, create partitionのsize, assign letterの値は各自の環境に読み替えてくだしあ。なお、select diskで指定する値はlist diskで確認できる。 回復パーティションの容量は1 GiBが公式の推奨値である。ここでは念には念を入れて3 GiB確保した。当然ながら、ディスクに回復パーティション分の空き領域が必要となる。足りなければ、ディスクの管理でC:ドライブを縮小するなりして確保してくだしあ。 select disk 0 create partition primary size=3072 format quick fs=ntfs label="Recovery tools" assign letter="T" set
1年以上放置してたWindows Updateが全然進まない件→解決
システム更新準備ツールを実行し（これが超時間食いで終了まで半日くらい掛かった）、Windows Updateエージェントを最新にして、もう一度システム更新準備ツールを実行（今度は2〜3時間で終了）した所、うちの環境では問題が解決した。それでも最初のWindows Updateが完了するまでは更に数時間かかったけど…。 BITSのトラブルシューティングやWindows Updateのキャッシュのクリアは然程意味がなさそうに思えた。特にキャッシュのクリアは意味がないどころか、逆に悪影響な気がした。どちらも何の根拠もない私見なので悪しからず。 しっかし、何もしてないのにOSの最重要コンポーネントがおかしくなるのは止めてもらいたいもんだね。Windows Updateがぶっ壊れるだけならまだいいが、ぶっ壊れた結果、関連のバックグラウンドタスクがCPUとメモリをバカ食いするのが頂けない。CPUを常時
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
