素晴らしきファイルシステムのデータ管理
ファイルシステムが一体どうやってデータを管理しているのか？ 単純な例を挙げながらその仕組みを詳しく解説しよう 私たちは普段、携帯電話やデジタルカメラで何げなく画像データなどを保存していますが、それらのデータが一体どこに・どんなふうに管理されているのか、あまり意識することはないと思います。これもファイルシステムが、あなたのデータ管理をすべて引き受けてくれているおかげです。 前回「ないと困る!? ファイルシステムのありがたみ」では、ファイルシステムのない世界をご紹介し、そのありがたみについて再認識しました。今回は、そのありがたいファイルシステムが一体どうやってあなたのデータを管理しているのかについて、単純な例を挙げながらその仕組みを解説したいと思います。 メタデータ ファイルシステムは、あなたのデータの配置状況をメモ書きして忘れないようにしておく必要があります。例えば、前回の例にあった記事1～
Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログ
社内で論文輪読会みたいなことやってて、そこで紹介した論文の内容についてです。 最近、Graphite に保存しているデータのバックアップ（データ同期）に rsync 使ってて、かなり遅いので困ってた。 LISA っていう 大規模システム、sysadmin 系のカンファレンスがあって、ここから論文探してたら、ちょうど巨大データの高速バックアップの実装の話があったので読んでみた。 論文概要 dsync: Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data - https://www.usenix.org/conference/lisa13/technical-sessions/presentation/knauth - Thomas Knauth and Christof Fetzer, Technische U
EXT3-fs error (device dev): ext3_journal_start_sb : Detected aborted journal
先日のことですが、あるサーバで DISK 障害が発生したために DISK 交換を行いサーバのリブートを行いました。すると /var/log/messages に見慣れないエラーメッセージが出力され、DISK が Read Only な状態になってしまいました。 Dec 1 13:34:53 srv01 kernel: ext3_abort called. Dec 1 13:34:53 srv01 kernel: EXT3-fs error (device sdb1): ext3_journal_start_sb: Detected aborted journal Dec 1 13:34:53 srv01 kernel: Remounting filesystem read-only 見慣れないエラーを見かけるとちょっとワクワクしちゃうのは変態エンジニアって証拠でしょうか・・・(〃▽〃) L
仙石浩明の日記: NFS と AUFS (Another Unionfs) を使って、ディスクレス (diskless) サーバ群からなる低コスト・高可用な大規模負荷分散システムを構築する
ディスクレス (diskless) サーバを多数運用しようとしたときネックとなるのが、 NAS (Network Attached Storage) サーバの性能。 多数のディスクレスサーバを賄え、かつ高信頼な NAS サーバとなると、 どうしても高価なものになりがちであり、 NAS サーバ本体の価格もさることながら、 ディスクが壊れたときの交換体制などの保守運用費用も高くつく。 それでも、多数のハードディスク内蔵サーバ (つまり一般的なサーバ) を 運用して各サーバのディスクを日々交換し続ける (運用台数が多くなると、 毎週のようにどこかのディスクが壊れると言っても過言ではない) よりは、 ディスクを一ヶ所の NAS にまとめたほうがまだ安い、 というわけで NAS/SAN へのシフトは今後も進むだろう。 そもそも CPU やメモリなどとハードディスクとでは、 故障率のケタが違うのだから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
