コラム - グーグルのクラウドを支えるテクノロジー | 第3回 ユースケースからデザインされたGoogle File System（パート1）｜CTC教育サービス 研修/トレーニング
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第3回 ユースケースからデザインされたGoogle File System（パート1） (中井悦司) 2016年10月 はじめに 今回は、2003年に発表された論文「The Google File System」から、Google File System（GFS）を紹介します。GFSは、数千台規模のクライアントがアクセスする分散型の共有ファイルシステムを実現するソフトウェアで、2003年に発表されたこの論文において、Google社内の開発、データ分析、そして、実サービス環境で使用されていることが公表されました。 GFSの特徴は、Google社内における共有ファイルの利用パターンに特化して設計されている点にあります。特定の目的を実現するために、で
なぜWindowsはまだNTFSを使っているのでしょうか？なぜフラグメンテーションが起きにくいLinuxのext4ではないのでしょうか？
回答 (3件中の1件目) NTFSも一応フラグメンテーションが起きにくいようには作られています。今のext4 FSに比べるとフラグメンテーションし易いですが、フラグメンテーションだけがファイルシステム性能や機能の指標ではないです。 わざわざ使う必要がないユーザーが多いかも知れませんが、e4defrag（ファイルのフラグメンテーションを直すツール）やe2freefrag（ext4もフリースペースのフラグメンテーションを防止できないのでその状況を知る為のツール）といったフラグメンテーション対策ツールがext4用に提供されています。ext4もフラグメンテーションを起こすので結局は運用にデフラ...
TabFS
Going through the files inside a tab's folder. For example, the url.txt, text.txt, and title.txt files tell me those live properties of this tab (Read more up-to-date documentation for all of TabFS's files here.) This gives you a ton of power, because now you can apply all the existing tools on your computer that already know how to deal with files -- terminal commands, scripting languages, point-
cat するたびに内容が変わるファイル？を作った
こんな感じ。 cat で連続して nowファイルの内容を表示している。ファイルを変更しているわけではないが、 表示するたびに内容が変わる。 # cat now 2018-12-27 00:21:20 # cat now 2018-12-27 00:21:21 # cat now 2018-12-27 00:21:23 Fuse-BindEx どういう仕掛けかというと、今回作成した bindex ファイルシステムを経由して、 上記ファイルにアクセスしているため。この bindex というファイルシステムは、 「実行ファイルが read されたら、そのファイルを execute した際の出力を内容として返す」 という動作をする。上記nowファイルの本当の内容はこちら。 #!/bin/bash date "+%F %T" 今回の場合、bindex 経由で cat (read) するたびに、dat
HDFSの現状と今後 (その1) - Qiita
まず、Apache Hadoop 3.0.0リリースおめでとうございます! 公式の記事: https://blogs.apache.org/foundation/entry/the-apache-software-foundation-announces26 ここ最近の大きめのHDFSの機能について、いくつか語ってみたいと思います 3.0.0でリリースされた機能 Erasure Coding Router based federation (2.9.0にもbackportされた) 3.1.0に入ることが確定した機能 (trunkにマージ済) Tiered storage 3.1.0に入るかわからない機能 (trunkにマージ前) Ozone: Object store for HDFS Erasure Coding JIRA: https://issues.apache.org/jira/
消すだけなのに rm -rf がいっつも長くて待ちきれない問題 - kuenishi's blog
rmコマンドで大量のファイルを削除しようとするとjournaldがめっちゃリソース持っていく件— bokko (@cubicdaiya) 2017年8月3日 今時のファイルシステムはみんなジャーナルもってて何かあったときにそこからリカバリする仕組みになってるので、当たり前といえばそうなんだけども。 （TODO: ここにファイルシステムのツリー＋ジャーナルのポンチ絵を手描きでも何でも描く） ご本尊のデータのツリーと何らかのWALを1セットで持っておくのはRDBだろうがファイルシステムだろうがそうは変わらない、で、削除についても並行制御をうまくやるために削除フラグをログに入れておいてあとで本尊のデータを整理するというのが基本的な設計になる。そこで私は立ち上がった（TL;DR: 特にオチとかはないです）。 rm -rf が遅いのは人類にとって損失ではないか。もっと速く完了するようにすれば、 rm
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてな流大規模データ処理
HDFS basics from API perspective