Petter Reinholdtsen recently blogged about ZFS availability in Debian. Many people have worked hard on getting ZFS support available in Debian and we would like to thank everyone involved in getting to this point and explain what ZFS in Debian means. The landing of ZFS in the Debian archive was blocked for years due to licensing problems. Finally, the inclusion of ZFS was announced slightly more t
By Kirk McKusick, Sean Quinlan Communications of the ACM, March 2010, Vol. 53 No. 3, Pages 42-49 10.1145/1666420.1666439 Comments During the early stages of development at Google, the initial thinking did not include plans for building a new file system. While work was under way on one of the earliest versions of the company's crawl and indexing system, however, it became quite clear to the core e
Disclaimer: The opinions expressed here are my own and do not necessarily represent those of current or past employers. Recent CommentsJames Hamilton on Seagate HAMRDio Phung on Seagate HAMRJames Hamilton on Pat SelingerMark Gandy on Pat SelingerJames Hamilton on Seagate HAMRArie van der Hoeven on Seagate HAMRJames Hamilton on Pat SelingerPat Selinger on Pat SelingerJames Hamilton on Seagate HAMRJ
図 1: ディスクの構造。 (A) トラック (B) (幾何学的)セクタ (C) トラックセクタ (D) クラスタ ディスクセクタ(英: Disk sector)とは、伝統的に、ディスクドライブ(磁気ディスクや光ディスク)のトラック[1]の一部分を指す[2]。単にセクタとも呼ぶ。 各セクタには一定量のデータが格納される。磁気ディスクの場合、1セクタは512バイト、光ディスクの場合、1セクタは2048バイトが典型的である(セクタ当たりのユーザーがアクセスできるデータの量)。 伝統的な定義[編集] 数学的(幾何学的)には、セクタ(sector は「扇形」の意)は、円板の中心から円周に向かって2本の直線を引いたときの間に挟まれた部分を意味する(図 1 の (B) 参照)。従って、いわゆるディスクセクタ(図 1 の (C))は、数学的セクタとトラックの交わった部分を指している。 コンピュータ業界で
Overview Sheepdog is a distributed storage system for KVM. It provides highly available block level storage volumes that can be attached to KVM virtual machines. Sheepdog supports advanced volume management features such as snapshot, cloning, and thin provisioning. sheep is a disk I/O management process, dog is a cluster management process, and KVM is patched virtual machine monitor
NILFS - 過去に遡れるファイルシステム NTTさんが開発中の NILFSを試しに使っています。 これは、ログ構造ファイルシステム( Log-structured file system)の一種で、簡単に言えば過去の状態に簡単に遡れることを特徴とするファイルシステムです。 もちろん、物理的なディスクの容量に制限を受けるのはあたりまえですが、ディスクの容量が許す限り、過去の複数の時点のファイルシステム全体の状態を保存しておくことができます。 さらに、それら過去の時点のファイルシステムを、読み込み専用の形でマウントすることができます。 過去の複数の時点の状態を保存していたら、すぐにディスクがいっぱいになってしまうのではないかという心配はいりません。 ファイルシステム全体のコピーをいちいち保存しているわけではなく、変化があったファイルの、変化があった部分だけを保存しているそうです。 この分野
2008年09月07日19:00 カテゴリiTech 雨降って地固まり、geom mirrorが壊れてZFSを導入する 今週は泣きっ面に蜂であった。 月曜日に(固定)電話が壊れ 火曜日にプリンターが壊れ.... という感じでいろいろなモノの寿命が尽きて、ついに 金曜日にファイルサーバーが壊れ と相成った。 しかし、こういう時こそものごとを非線形によくするチャンスである。転んでタダで起きるのは弾ではない。特に他は待てるが、ファイルサーバーは待てない。他の直しでもちょっとした発見があったのだが、まずはファイルサーバーの修復、というより大刷新について書いておきたい。 といっても、サーバーをまるごと新調したわけではない。交換したのはディスク、そしてファイルシステム。 Before FreeBSD 6-STABLE SATA 250GB x 4 RAID1 by geom (gmirror) UFS
この疑問はとても自然です。というのも、ファイルシステムは単純にデータを管理するための手段で、私たちが日常コンピュータを利用する上で、すでに十分なファイルシステムは提供されています。もちろん、一昔前は扱えるファイルサイズやファイル名の長さなどに幾分厳しい制限があり、不満を感じた人もいるかもしれません。ですが、最近のファイルシステムに対してそういった意味で問題を感じることはほとんどないと思います。 そういった意味でファイルシステムを新しく作る必要性はないように思えます。 ところが、実は近年、ファイルシステムの進歩は留まるどころかむしろ加速している、というのが著者の見解です。 最近登場した新しいOSに、ファイルを過去の状態に復元する機能が相次いで搭載されました。たとえばWindows VistaのシャドウコピーやMac OS Xのタイムマシーンがそうです。実はこれらの機能はファイルシステムによっ
ようこそボボンハウスへ 2ちゃんねる入り口 荒らしやサーバへのアタックなどがあったとしても、 2chでは個人を特定して遮断することは技術的に不可能です。 なので、そういった行為をする人にアクセスする権限を与えているプロバイダーに対応を御願いしています。 ただ、プロバイダーによってはそういった対応をしてくれないところがあります。 例えば、今あなたが使っているプロバイダーです。 このページは、プロバイダーに対応を御願いしてもプロバイダーが対応してくれない場合に飛ばされるページです。 そういったわけで、迅速な解決を望む人はプロバイダーのサポートに電話とかするといいかもしれません。 ボボンハウスとは、 (´・ω・`)やぁ。ようこそボボンハウスへ。 このページはサービスだから、まず見て落ちついて欲しい。 うん、「また規制」なんだ。済まない。 FOX★の顔も三度って言うしね、謝って許してくれと言っても
XFSの歴史 XFSはSilicon Graphics(以下SGI:編注)が開発したジャーナリングファイルシステムである。XFSの開発が開始された当時、SGIはすでにEFS(Extent File System)というファイルシステムを持っていた。SGIがXFSで目指したものは、次世代の拡張性を考慮した64bitファイルシステムを新規開発することだった。 XFSは、1994年後半にリリースされたIRIX 5.3(IRIX 5.3 with XFS)に初めて搭載された。1996年にIRIX 6.2がリリースされると、全SGIシステムに標準でインストールされるようになった。1999年前半にはLinuxへ移植され、GPL(GNU General Public License)の下でオープンソースとして公開された。 最初のLinux用XFSであるXFS 1.0 for Linuxは、カーネル2.4
I/O性能 十分メモリに乗るくらいのファイルサイズで比較 1Gbyteのファイルに対しread,writeを行います。 I/Oサイズごとに速度が異なることもあるので、参考になればと思います。 ただしwriteはsync無しとsync有りの2通り 今回はシェル+ddコマンドで仮の測定を行いました。測定方法は検討中(6/26) かなり予想と異なる結果なので、Bonnie等を検討中 read測定 time dd of=/dev/null if=testfile bs=1K count=1048576 time dd of=/dev/null if=testfile bs=2K count=524288 time dd of=/dev/null if=testfile bs=4K count=262144 time dd of=/dev/null if=testfile bs=8K count=1
Linuxのcloseは暗にfsyncするから、ここであげられている 100000回繰り返し open 8K write close というパターンだとfsyncコストが見えちゃうので良くないんじゃないかな とのことで、そうなのか! と思ったので例によって深追いしてみました。 まず fsync(2) の実装は fs/sync.c にあります。 asmlinkage long sys_fsync(unsigned int fd) { return __do_fsync(fd, 0); } static long __do_fsync(unsigned int fd, int datasync) { struct file *file; int ret = -EBADF; file = fget(fd); if (file) { ret = do_fsync(file, datasync);
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く