android sdcard存储方案（基于fuse文件系统）：之二

续《android sdcard存储方案（基于fuse文件系统）：之一》，再聊聊基于android sdcard存储方案（基于fuse文件系统）：之二，

以后有空再谈谈该方案的缺点，及优化方案。

一、android GB 及JB、KK版本内置sdcard效果对比图

从上面效果对比图，我们可以发现android fuse sdcard 有如下两个优点：

1、使用fuse后 /data 和  /sdcard0 是共离一块分区，这块分区的空间/data和/sdcard0 动态享用， 用户使用灵活。

2、去掉了fat32文件系统，这样也免去了一个license的风险。

二、fuse的标准工作流程图

from:  http://en.wikipedia.org/wiki/Filesystem_in_Userspace

Filesystem in Userspace

这里重点说明libfuse的作用：libfuse为开发者提供了接口fuse_operations开发者只需要实现这组接口，然后调用fuse初始化接口：fuse_mount()、fuse_new()、fuse_loop()即可实现一个用户空间文件系统。这样为开发多种fuse文件系统带来很多方便。

三、android fuse sdcard架构图及source code

1、source code：

\system\core\sdcard\

\frameworks\base\cmds\installd\    JB

./frameworks/native/cmds/installd/   KK

\kernel\fs\fuse\

2、fuse操作流程图：

android fuse sdcard的操作流程说明：

步骤１：黑色箭头所示，app通过fuse向sdcard dameon 发出操作请求

步骤２：红色箭头所示：sdcard damon 实际完成操作，比如此例：通过vfs、ext４向实际存储器操作

步骤３：蓝色箭头所示：sdcard damon通过fuse向app反馈操作结果

android fuse sdcard  流程和标准fuse流程图最大不同点在于：

android没有直接移植标准的libfuse，而是重写了相关代码，将libfuse的功能集成到sdcard dameon。

这样做的我能想到的好处，可能就是函数调用的层次少了一些，可能效率会好点。

一直想不明白android为什么不移植libfuse ？

3、fuse sdcard 的mount状态，如下图：

四、使用fuse sdcard 带来的一些问题及解决方法

1、/data和/sdcard 动态占用空间，如果用户通过/sdcard将整个分区填满，则会导致系统无法启动。

时，仅允许系统写入，不允许普通 app 写

  解决办法，就是设置一个/sdcard/可用的上限，不至于导致系统崩溃至无法启用。

 具体可以参考mtk修改的代码：\kernel\fs\fuse\inode.c (LIMIT_SDCARD_SIZE包宏处)

static void convert_fuse_statfs(struct kstatfs *stbuf, struct fuse_kstatfs *attr)
{
stbuf->f_type    = FUSE_SUPER_MAGIC;