takano32 曰く、 "Googleが提供するWEBメイルサービスGmailのアカウントをLinuxのファイルシステムとしてマウントするGmailFSの登場が話題を呼んでいます.(本家記事)GmailFSはPythonによる実装で,ファイルシステムの実現にはFUSE,Gmailへのアクセスにはlibgmailを用い,アカウントのマウントを可能にしています.Gmailでは1GBのスペースを利用できますが,このような使い方をするとすぐに限界の容量に達してしまいそうです."
Samba Over GmailFSなら (スコア:5, すばらしい洞察)
ファイル名だけでなくExcelやPowerPoint,PDFも
文章の中身からGoogle検索できるのだろうか?
実験してみたいなぁ
Re:Samba Over GmailFSなら (スコア:0)
自分のPCにマウントされたファイルシステムをGoogle検索できるのがミソってことかしら?
ところでGmailのことを良く知らないのですが,まさかmailの内容をだれでも検索できるわけでは無いですよね???
Re:Samba Over GmailFSなら (スコア:0)
Re:Samba Over GmailFSなら (スコア:0)
実際に試しています (スコア:5, 参考になる)
3つのメールでひとつのファイルを表現するみたいで、オーバーヘッドも無視できませんが、それでもタダで1GBのオンラインストレージを入手できちゃうというのはおもしろいですね。
問題はこの使い方をする人が増えたときですかね。googleが本当に人数分のストレージを用意できるのでしょうかね...
あと好ましくなさげなものとしては、アカウントを公開して、怪しいファイルの交換に用いたりもできちゃいそう。
# 本家の記事は読んでないので(読めよ、重複した意見でしょうがID
-- やさいはけんこうにいちば〜ん!
Re:実際に試しています (スコア:1, 興味深い)
Re:実際に試しています (スコア:4, 参考になる)
試しにカーネルソースを展開して、そのtimeを記録しようと思ったのですが、ディレクトリの作成がうまくいってないみたいで、
linux-2.6.8.1/include/
tar: linux-2.6.8.1/include: mkdir 不能: そのようなファイルやディレクトリはありません
linux-2.6.8.1/include/asm-parisc/
tar: linux-2.6.8.1/include/asm-parisc: mkdir 不能: そのようなファイルやディレク トリはありません
という始末。中途半端にファイルができているため、このディレクトリ上でlsすると
ls: linux-2.6.8.1: そのようなファイルやディレクトリはありません
ls: linux-2.6.8.1: そのようなファイルやディレクトリはありません
ls: linux-2.6.8.1: そのようなファイルやディレクトリはありません
ls: linux-2.6.8.1: そのようなファイルやディレクトリはありません
ls: linux-2.6.8.1: そのようなファイルやディレクトリはありません
となってしまいました。
ということで圧縮したMS-DOS形式っぽいファイルを置く程度にしとくのが吉かと思います。
ということでcpでアーカイブそのものを転送してみてます。相当時間がかかると思いますが後で出しときます。
-- やさいはけんこうにいちば〜ん!
Re:実際に試しています (スコア:3, 参考になる)
densuke@yuzu% sudo time cp -v (どこそこ)/linux-2.6.8.1.tar.bz2 .
`(どこそこ)/linux-2.6.8.1.tar.bz2' -> `./linux-2.6.8.1.tar.bz2'
0.06user 1.16system 13:09.72elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2major+202minor)pagefaults 0swaps
ls (どこそこ)/linux-2.6.8.1.tar.bz2 -l
-rw-r--r-- 1 densuke densuke 35628066 2004-08-14 20:13 (どこそこ)/linux-2.6.8.1.tar.bz2
上り帯域は実測80kbpsぐらいだったかな、だとすると単純転送なら7分台なので、1.5倍ぐらいのオーバーヘッドなのね。
これはgmailのプロトコル的な問題か、一度ユーザ空間を経由したことによるオーバーヘッドなのかはイマイチ不明。
なお、tarでgmail上のファイルから展開するような実験はする気ありませんので...
-- やさいはけんこうにいちば〜ん!
Re:実際に試しています (スコア:2, おもしろおかしい)
じゃあ
dd if=/dev/zero of=${GMAIL}/swap.file bs=1024k count=512
swapon ${GMAIL}/swap.file
で スワップ領域 を.
# どこかで問題が出るような...
とりあえず、ソースリスト。 (スコア:3, 参考になる)
前のストーリー (スコア:2, 興味深い)
誰でも思いつく事か。
それを実装する情熱があるかどうかが問題だね。
画像掲示板に応用すると (スコア:2, 興味深い)
画像掲示板にアップするようなfsを作る事も出来ますね。
実は既に水面下で実現してるのかもしれませんが、
暗号通信や違法ファイルのやり取りにも使われてしまうなぁ。
モバイル用途で (スコア:1)
似たようなサービスが有料で有ったような...
Re:モバイル用途で (スコア:0)
Re:1GBをどう捉えるか (スコア:3, すばらしい洞察)
容量は増やせるね。
Re:1GBをどう捉えるか (スコア:2, おもしろおかしい)
RAID5などを構築すればディスクアクセスも速く..はならないか.:)
旅に出ます.(バグを)探さないで下さい.
Re:1GBをどう捉えるか (スコア:2, 興味深い)
1つアカウントを乗っ取られてもデータの内容までは分からないんで、
オンラインストレージとしての信頼性は高いのではないかと。ほんとか?
Re:1GBをどう捉えるか (スコア:1)
が始まったら RAID5 に移行するとか。
Re:1GBをどう捉えるか (スコア:0)
容量n倍、速度もn倍!(nはギガメールサービスの数)
どれか1つのサービスが落ちたら...?
汎用冗長化ファイルシステムが求められている! (スコア:2, 興味深い)
>容量n倍、速度もn倍!(nはギガメールサービスの数)
>どれか1つのサービスが落ちたら...?
という危険もあるのでRAID5、と。
いや、これはさらに押し進めて メールサービス業者ごとに
危険性(サービス廃止、アカウント停止)と、全体的なデータの冗長度を加味した
データの振り分けができればいいんじゃないか?
# gmail 1: yahoo 0.7: hotmail 0.01
# 全体冗長度 1.5(<全メールアカウントのうち 2/3が生きてたらデータ復元可能) とか
そんなストレージ毎の信頼性の設定と、冗長度を調整できる
プロトコルってあるんですかね?
何か構想レベルではありそうだな。
HDDとかだと処理のオーバヘッドが大きすぎて実用化できなさそうだけど
こんなもともと重いファイルシステムだから
細かいパフォーマンスはおいとけるとして誰か作ってくんないかなぁ・・・
Re:1GBをどう捉えるか (スコア:1)
結果的にネットワーク上のファイル自体をseekできるわけではないため、スワップみたいに一部分だけ変更するようなことをしても全体を再転送でとんでもないオーバヘッドが発生することになります。
RAIDに使おうものならそれはもうガクブルかと。
-- やさいはけんこうにいちば〜ん!
Re:1GBをどう捉えるか (スコア:1)
GmailFSの実装の詳細は,知りませんが.
1GB/1mail*1mail で実装しないで,
1MB/1mail*1024mail とかで実装すれば,
mailサイズ単位のランダムアクセスは可能では?
(各mailの識別は, Subject: で.)
Re:1GBをどう捉えるか (スコア:1)
Re:GmailFSが可能なら、LivDooFSも。 (スコア:2, おもしろおかしい)
...作ってって言われても作れないけど :-p
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
Re:GmailFSが可能なら、LivDooFSも。 (スコア:0)
あればそれなりに需要ありそうなんだけど...
Re:GmailFSが可能なら、LivDooFSも。 (スコア:0)