我的又一个 fuse 客户端——upyunfs
我写 fuse 客户端可能有点上瘾，是因为我觉得对于在线存储类的服务，能够映射到本地存储，对用户来说是路径最短，学习成本最低、体验最友好的方式。而要实现类似的效果，据我所知要么用 fuse 把远端的存储挂载到本地（如 sshfs、amazon s3fs），要么写个后台服务实现本地和远端的双向同步（同步远端可以轮询或用某种 push 技术，同步本地可以用 inotify，典型案例是 dropbox）。而我之所以倾向前者，是因为 fuse 的实现成本要小很多，对于个人开发者来说性价比完胜。 有了上述前提，什么专门的 GUI 管理工具啦，专门的 shell 啦，在我看来都比较无聊——当远端的文件系统已经变成本地的一部分时，用户可以使用任意自己熟悉的文件管理工具（无论 GUI 还是 CLI），可以使用任意自己熟悉的 shell 环境（包括相应的各种工具），来完成对远端的文件管理任务。比如将 dropbox 同步到 upyun，在我看来只需要这样就可以了： upyunfs -b lyman_foo ~/cloud/upyun # 挂载 upyunfs rsync -avh ~/cloud/dropbox/ ~/cloud/upyun/ # 用 rsync 同步两个文件夹 所以看到 upyun 搞了 开发者比赛 的时候，我实在是忍不住，便写了这个 upyunfs 。 对实现细节不感兴趣的同学可以忽略下面的文字了，不过还是希望各位能给 upyunfs 投个票：到 项目页面 里找到 upyunfs-for-UPYUN，点击「投票」按钮即可。 接下来大概分析一下 upyunfs（以及类似存储系统）的实现要点。 一、技术选择 fuse 有 各种语言的 binding ，从执行效率角度考虑首选当然是 c/c++。但是如 upyun 这样提供 RESTful 接口的服务，用到字符串操作的地方不少，所以用脚本写起来更方便。python 的 binding 我试过一次，问题不少文档不多，所以我一直用 perl。 二、roadmap 基本功能 这个阶段基本上只要做好 fuse 回调和 RESTful api 的映射就好了。具体一点，在线存储系统基本上必不可少的 upload/download/list 操作，大抵就可以对应到 fuse 的 read/wri...