2009/02/14: PerfectDisk 2008の"空き領域の結合を重視"オプションをつけた結果を掲載しました SSDにおける断片化の影響について SSDにはデフラグは不要という主張を時々目にしますが、実際にはSSDもデフラグの効果はあります。ただし、Windows標準のデフラグはあまり効果がありません。 SSDは、ランダムリード速度に優れたストレージです。そのため、書き込み済みのファイルが断片化していても、そのファイルの読み込み速度はあまり低下しません。 一方、JMF602搭載製品など、一部のSSDはランダムライトがHDDより遅いという欠点を持っています。それらのSSD上の空き領域が断片化していると、書き込み速度が低下してしまいます。Windows標準のデフラグは、積極的に空き領域のデフラグを行わないため、書き込み速度を回復させる効果は高くありません。 空き領域の断片化は、書き込
「Lest We Remember: Cold Boot Attacks on Encryption Keys(概要)」という発表がありました。 「Full Research Paper」も公開されています。 プリンストン大学での研究発表です。 世の中にある非常に多くのハードディスク暗号化は突破できると書いてありました。 RAM(メモリ)に残った秘密鍵を読み込んでしまえば暗号を複合できるという発想です。 電源を切るとRAMに入った情報は直ぐに消えてしまうわけではなく、時間と共に徐々に消えて行きます。 そのRAMに含まれる暗号の秘密鍵を読み出してしまえというわけです。 いきなり電源を切って直ぐに冷却材などで急速に冷却するという手法を使うと、RAMからデータが消失するまでの時間を飛躍的に延ばす事も可能であると研究では述べています。 今回の研究者達はTrueCrypt、Apple FileVau
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
物理的にバッドセクタが発生して読み込めなくなったハードディスクをソフトウェアの力で修復し、再度利用可能にするという、にわかには信じられないソフトウェアです。 修復可能なのは、磁性の極性変化による物理的エラー。それ以外の物理的破損によるエラーはさすがに修復できません。しかし、大体6割程度はこの磁性エラーなので、このソフトを使えば60％の確率で復活できるらしい。 前回、ハードディスクの診断を行った結果、全く使い物にならないダメージを受けていることが既に判明しているわけですが、果たして、復活できるのでしょうか？ というわけで、実際に試してみました。 HDD Regenerator http://www.dposoft.net/#b_hddhid 59.95ドルのシェアウェアで、デモ版では実際に最初に見つけた1セクタ分のバッドセクタを修復してくれます。極端な話、1セクタ見つける度に再起動してやり直
かの有名な「パーティションマジック」と同じ作者の作ったフリーソフト。ライセンスはGPL。ソースコードも公開されています。基本的に「パーティションマジック」と同じ操作性で機能も高度な機能以外はほとんど同じです。無料でここまでのものが利用できるとは…。 ダウンロードは以下のサイトから。 Partition Logic - Download http://partitionlogic.org.uk/download.html CD-Rに焼いて利用するCD-ROM版と、フロッピーディスクから利用するフロッピー版があります。 基本的な機能や制限は以下の通り。 Partition Logic - About http://partitionlogic.org.uk/about.html パーティションの作成、削除、フォーマット、デフラグ、リサイズ、移動、属性比較ができます。また、ハードディスク全体をコ
正確にはオープンソースソフトなわけですが、非常に優秀です。ISOイメージをダウンロードしてCD-Rに焼けばライブCDが完成。そこから起動すればパーティション操作がグラフィカルな操作画面から可能になります。 パーティションのサイズ変更や新しいパーティションの作成、フォーマットの変換、まるごとコピーなどが簡単にできます。 対応しているのはExt2、Ext3、FAT16、FAT32、JFS、ReiserFS、Reiser4、NTFS、XFSなど。 GParted http://gparted.sourceforge.net/ ダウンロードはこちらから（LiveCDの方） http://gparted.sourceforge.net/download.php パーティションのサイズ変更はこのような感じで可能 新しくパーティションを作る場合はこんな感じ フォーマット変換は選ぶだけで済む 各フォーマッ
今日の呑み会ネタ実装。 Ruby の世界をファイルに抽象化します。なんでもファイル。 http://shinh.skr.jp/ttyplay/rubyfs.html i@u /mnt/tmp> cat Time/now Sun Mar 19 01:41:00 JST 2006i@u /mnt/tmp> cat Array/new > @a= i@u /mnt/tmp> echo '"foo"' '"bar"' '"baz"' > @a/push i@u /mnt/tmp> cat @a/push ["foo", "bar", "baz"] i@u /mnt/tmp> cat @a/size 3 i@u /mnt/tmp> cat @a/pop "baz" i@u /mnt/tmp> cat @a/size 2FUSE と Ruby FUSE を用いて作りました。 100 行足らずでぼくにも
![[Program][Ruby] RubyFS](https://cdn-ak-scissors.b.st-hatena.com/image/square/afd60a062645079ab63dbe177f5e8121cd446c8c/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fogimage.blog.st-hatena.com%2F12704346814673860805%2F8454420450066435149%2F1411773180)
http://www.ruby-lang.org/ja/man/?cmd=view;name=pathname 先日のRails勉強会でetoさんにPathnameというパスやファイル名のすごい便利なライブラリを教えて貰った。で、早速使ってみたところめっちゃ便利でいま書いてるアプリケーションじゃほとんどのファイル名の操作に使ってるという。 使い方はめっちゃ簡単でパスやファイル名を引数としてオブジェクトを作るだけ。 require 'pathname' file = '/tmp/foo' path = Pathname.new file で、これの何が便利っていうとリファレンスマニュアルのメソッドを眺めて貰うと解るんだけど、ファイル関係の操作が何でもできてしまう。通常だとFileオブジェクトを作るには実体が無いとダメなんだけど無くてももちろん作れるため str = IO.read(file)
I'm Dominic Giampaolo. I program computers for a living. For a long time I lived in Silicon Valley but now reside in Maine. I've worked for a number of different computer companies over the years: SGI, Be Inc., Google (briefly), and QNX. I started at Apple in 2002 and am still there. One of my claims to fame is writing the Be File System. I also wrote a book about BFS called, "Practical File Syste
4. Server File Cache → Storage 図4. nfs request flow 本章では図4の赤い部分、 Server File Cache から Storage までの経路に焦点を当てる。 ここは最後のパス、 Storage と IO しなくてはいけない 場合に必ず通るパスである。 図上では Server File Cache, Local File System, Storage は 3つの異なるユニットであるかのように描画しているが、 実際にはこの3ユニットの性能と特性は互いに影響しあって 全体で1つの性能を引き出す。 このため、この3つのユニットはバラバラに評価するわけには行かない。 普通に言う場合は、 この3つのユニットの性能を逢わせて Local File System の性能 と呼ぶ。 広義の nfs では、 Storage の部分は他の物にもなりうる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
