タグ

filesystemに関するcon_mameのブックマーク (8)

  • Linux の ext4 ファイルシステムで間違って上書きしたファイルを復旧させた - 鈴木うどんの横須賀おもしろ生活

    結論 ext4magic 最高!!!!111 やったこと % ext4magic “デバイス名に” -r -a “このunixtimeから” -b “このunixtimeまで存在していた” -f “このファイル名のファイルを復旧する” 実例 /dev/md0 上の昨日の20:00から20:30の間まで存在していた udonchan/backup.tar を復旧させたい % ext4magic /dev/md0 -r -a $(date -d "-1day 20:00 +%s") -b $(date -d “-1day 20:30 +%s) -f "udonchan/backup.tar" どうしてこうなった 年末なので OSX をクリーンインストールしようとして ~ をバックアップしたが間違って上書きして消した。 具体的に? ~ をサーバ上にバックアップするぜ % tar cf -C /U

    Linux の ext4 ファイルシステムで間違って上書きしたファイルを復旧させた - 鈴木うどんの横須賀おもしろ生活
  • 『【研究レポート抜粋】P2P Replicated File Store の実装』

    上記表の通り、仮想ノードにより偏りは少なくなったが、仮想ノードの導入により以下の問題が発生する。 ノード追加時のデータコピーの局所性物理ノードだけでコンシステントハッシングを行う場合、ノードを追加した際は新ノードが配置される場所の次に位置するノードからデータをコピーするだけでよいという特徴がある。 しかし仮想ノードを導入すると仮想的なノードが入り混じる形で配置されるので、結果的に全ての物理ノードにデータコピーが発生する。 そのため、P2P Replicated File Storeではオンラインでのノード追加機能を諦め、ノード追加時には再起動による再配置に絞ることにした。 耐障害性 レプリケーション P2P Replicated File Store では、ファイルの格納時にノード側でレプリケーションを自動的に行う。 上図のようにシーケンシャルにファイルレプリケーションを行う。 非同期での

    『【研究レポート抜粋】P2P Replicated File Store の実装』
  • Linuxでうっかりrm -rfしちゃったけど復活出来たよー\(^o^)/ - y-kawazの日記

    サーバのファイル整理作業をしていたところ…、 間違えてrm -rfしてしまった! ぎゃーバックアップもねー! 長いこと生きてたらこんな経験の1度や2度はありますよね? えぇ、ついさっきやらかしちゃいましたwwオワタwww 速攻「rm 復活」とか「rm 取り消し」とかでググッたねw、したらmcってプログラムのUndelete機能使えばよいって情報が出てくるが、どうやらこれext2じゃないと使えないっぽいぞ…、うちext4だ。 混乱。以下ターミナルのヒストリーより実況。 ## こーいうときはまずあれだ、現場保存! ## まずは今いるパーティションを確認 # df -hT Filesystem Type サイズ 使用 残り 使用% マウント位置 /dev/sdb2 ext4 193G 6.9G 176G 4% / /dev/sdb1 ext3 194M 22M 163M 12% /boot /d

    Linuxでうっかりrm -rfしちゃったけど復活出来たよー\(^o^)/ - y-kawazの日記
  • Linuxファイルシステムまとめ | エンタープライズ | マイコミジャーナル

    Make Tech Easier - Uncomplicating the complicated, making life easier 代表的なファイルシステムに絞っても、Linuxにはいくつか選択候補になるファイルシステムがある。ディストリビューションの指針や評価ごとに違うファイルシステムが採用されたり、バージョンがあがるごとにデフォルトのファイルシステムも入れ替わる傾向がある。インストール時に選択できることが多い。 どのファイルシステムを選択するかは用途ごとに適切なものを選べばいいことになるわけだが、それぞれを比較するのは少々大変だ。そうした場合に役に立つ情報がChoosing The Best Linux Filesystem For Your PC - Make Tech Easierにおいて公開された。代表的なLinuxファイルシステム(Ext2、Ext3、Ext4、Reis

  • ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改

    ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号(メモリアドレスみたいなもんだな)を調べて、そのブロック番号を指定してHDDやSSDにアクセスす

    ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改
  • Dokan >> SSHFS

    PTP: Accessing Photos, videos and camera data as a disk mount iOS automatically presents modern devices as cameras when they're connected over USB. This uses Picture Transfer Protocol (PTP) which is a fairly limited system allowing you to copy photos back and forth. You'll probably recognise the DCIM folders that photos tend to appear in. PTP has a number of drawbacks: most obviously, you can't ac

    Dokan >> SSHFS
  • やたーはてなダイアリーファイルシステムできたよ\(^o^)/ - 川o・-・)<2nd life

    はてなダイアリーが AtomPub で編集できるようになったので、早速 fuse を使ってファイルシステムを作ってみました。こんな感じに使えます。 http://rails2u.com/tmp/diary_fuse/fuse.htm (動画) /create に保存すると現在時刻で作成 /20080820101010 など、エントリーを編集可能。保存で更新。 rm するとエントリーを削除 /\d{14} 的なファイル名で保存すると、その時刻のエントリーを作成 などなど。Ruby の FuseFS を初めて使ってみましたが、結構簡単にファイルシステムをいじれて便利ですね。ちなみに文の改行周りがおかしくなるというアレな挙動をして、全然実用できませんが、AtomPub 使うとこんな事もできるよーという例として見ていただければ。 ソースコードは以下です。

    やたーはてなダイアリーファイルシステムできたよ\(^o^)/ - 川o・-・)<2nd life
  • 1