1、Fuse(Filesystem in Userspace)
早期的android系统没有使用fuse文件系统后来android为了控制不同APP对文件访问的权限，使用了fuse文件系统。早期手机内置SD卡使用一个独立vfat文件系统格式的分区。使用fuse之后，将手机内置SD卡与userdata分区合并成为一个分区。userdata分区使用ext4文件系统存储数据，访问userdata分区是直接操作ext4文件系统，而访问内置SD卡，则是先访问fuse文件系统，然后再访问ext4文件系统。
fuse文件系统的基本方法是，创建fuse设备，并将fuse设备挂载到与内置SD卡目录关联的目录。那么，对内置SD卡的访问变成了先访问fuse文件系统，再访问ext4文件系统。fuse的内核部分创建了多个队列，其中包含一个pending队列和一个processing队列。每当有调用者对内置SD卡的系统调用时，fuse把文件访问路径转换为对ext4文件系统的操作路径，设置对应的操作码，并放入一个请求中。fuse在用户态有3个监控线程，循环地读取fuse设备。对fuse设备的读取操作在内核部分转换从pending队列读取请求，如果队列中没有请求，则对应的线程进入睡眠状态。监控线程读取到pending队列中的请求后，把请求转换为对ext4文件系统的系统调用操作。系统调用执行完成后，监控线程把执行结果写入到fuse设备，对fuse设备的写操作在内核部分转换为把结果放入processing队列。processing队列依次取出结果，返回给调用者。
Fuse访问文件流程
维基百科：Fuse文件系统简介
从用户空间到列表文件（ls -l / tmp / fuse）的请求被内核通过VFS重定向到FUSE。FUSE然后执行注册处理程序（./hello）并将请求传递给它（ls -l / tmp / fuse）。处理程序返回一个响应给FUSE，然后它被重定向到最初发出请求的用户空间程序。
由上图可以看出Fuse需要进行多次的用户态与内核态交互，这样就会造成切换开销
实例分析
摘自国外一个博客Why does FUSE on Android suck
cat过程中的strace
root@android: # cd /sdcard
root@android:/sdcard # cat test.txt
root@android:/sdcard # strace -f -e open,openat,read,close cat test.txt
(..)
>>stripped output related to loading "cat" by shell<<
(..) = 0
openat(AT_FDCWD, "test.txt", O_RDONLY) = 3
read(3, "1234\n", 1024) = 5
read(3, "", 1024) = 0
close(3) = 0与此同时sdcard daemo 工作流程
root@android: # ps | grep sdcard
media_rw 714 1 23096 1528 ffffffff 81ca6254 S /system/bin/sdcard
root@android: # strace -f -p 714
Process 714 attached with 3 threads
[pid 916] read(3, <unfinished ...>
[pid 915] read(3, <unfinished ...>
[pid 714] read(4, <unfinished ...>
[pid 916] <... read resumed> "1\0\0\0\1\0\0\0\2\234\3\0\0\0\0\0\200\200@\200\177\0\0\0\0\0\0\0\0\0\0\0"..., 262224) = 49
[pid 916] faccessat(AT_FDCWD, "/data/media/0/test.txt", F_OK) = 0
[pid 916] newfstatat(AT_FDCWD, "/data/media/0/test.txt", {st_mode=S_IFREG|0664, st_size=5, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid 916] writev(3, [{"\220\0\0\0\0\0\0\0\2\234\3\0\0\0\0\0", 16}, {"\200\261\317\200\177\0\0\0\223(\0\0\0\0\0\0\n\0\0\0\0\0\0\0\n\0\0\0\0\0\0\0"..., 128}], 2) = 144
[pid 915] <... read resumed> "0\0\0\0\16\0\0\0\3\234\3\0\0\0\0\0\200\261\317\200\177\0\0\0\0\0\0\0\0\0\0\0"..., 262224) = 48
[pid 916] read(3, <unfinished ...>
[pid 915] openat(AT_FDCWD, "/data/media/0/test.txt", O_RDONLY|O_LARGEFILE) = 5
[pid 915] writev(3, [{" \0\0\0\0\0\0\0\3\234\3\0\0\0\0\0", 16}, {"\260p\300\200\177\0\0\0\0\0\0\0\0\0\0\0", 16}], 2 <unfinished ...>
[pid 916] <... read resumed> "P\0\0\0\17\0\0\0\4\234\3\0\0\0\0\0\200\261\317\200\177\0\0\0\0\0\0\0\0\0\0\0"..., 262224) = 80
[pid 915] <... writev resumed> ) = 32
[pid 916] pread64(5, <unfinished ...>
[pid 915] read(3, <unfinished ...>
[pid 916] <... pread64 resumed> "1234\n", 4096, 0) = 5
[pid 916] writev(3, [{"\25\0\0\0\0\0\0\0\4\234\3\0\0\0\0\0", 16}, {"1234\n", 5}], 2) = 21
[pid 915] <... read resumed> "8\0\0\0\3\0\0\0\5\234\3\0\0\0\0\0\200\261\317\200\177\0\0\0\0\0\0\0\0\0\0\0"..., 262224) = 56
[pid 916] read(3, <unfinished ...>
[pid 915] newfstatat(AT_FDCWD, "/data/media/0/test.txt", {st_mode=S_IFREG|0664, st_size=5, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid 915] writev(3, [{"x\0\0\0\0\0\0\0\5\234\3\0\0\0\0\0", 16}, {"\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\224(\0\0\0\0\0\0\5\0\0\0\0\0\0\0"..., 104}], 2) = 120
[pid 916] <... read resumed> "@\0\0\0\31\0\0\0\6\234\3\0\0\0\0\0\200\261\317\200\177\0\0\0\0\0\0\0\0\0\0\0"..., 262224) = 64
[pid 916] write(3, "\20\0\0\0\0\0\0\0\6\234\3\0\0\0\0\0", 16) = 16
[pid 916] read(3, "@\0\0\0\22\0\0\0\7\234\3\0\0\0\0\0\200\261\317\200\177\0\0\0\0\0\0\0\0\0\0\0"..., 262224) = 64
[pid 916] close(5) = 0
[pid 916] write(3, "\20\0\0\0\0\0\0\0\7\234\3\0\0\0\0\0", 16) = 16
[pid 916] read(3, <unfinished ...>
[pid 915] read(3, ^CProcess 714 detached
Process 915 detached注意关注进程号，其流程如下
1. userspace 程序的系统调用将由内核的Fuse驱动程序处理，即916进程
2. 内核中的Fuse驱动程序通知userspace守护进程(sdcard)有关新请求的信息
3. userspace守护进程读取 /dev/fuse
4. userspace守护进程解析命令并识别文件操作，如：open、read
5. userspace守护进程调用实际的底层文件系统，如EXT4、F2FS
6. 真实文件系统在内核处理请求并返回userspace
7. 如果userspace修改文件数据其将再次通过/dev/fuse/传递给内核
8. 内核完成底层真实文件系统调用并将数据移动到userspace的应用程序，如cat
性能
由于Fuse有多次用户态和内核态切换这样势必会造成性能的损失，性能劣于真实文件系统。少量文件单次访问可能无法对比出差异，但当文件量增大就会产生质的变化。安卓应用在访问数据大部分都是以小文件居多，这样就会造成性能的损失，这也是为什么在android O上使用新的SDcardfs文件系统原因。下面用EXT4和Fuse对比
拷贝单个大文件对比
EXT4
root@android:/data # echo 3 > /proc/sys/vm/drop_caches //清除缓存，会释放pagecache、dentries、inodes缓存，这样就会直接反应真实文件系统性能
root@android:/data # dd if=bigbuck.in of=bigbuck.out bs=1m //bigbuck.in为data中存放的文件，同样也可以选择较大文件做对比测试
691+1 records in
691+1 records out
725106140 bytes transferred in 10.779 secs (67270260 bytes/sec)Fuse
root@android:/sdcard # echo 3 > /proc/sys/vm/drop_caches
root@android:/sdcard # dd if=bigbuck.in of=bigbuck.out bs=1m
691+1 records in
691+1 records out
725106140 bytes transferred in 13.031 secs (55644704 bytes/sec)由上面可以看出EXT4和Fuse存在一定差异，Fuse比EXT4低17%
- 小文件拷贝 10000个5kB文件
EXT4
root@android:/data # echo 3 > /proc/sys/vm/drop_caches
root@android:/data # time cp small/* small2/
0m17.27s real 0m0.32s user 0m6.07s systemFuse
root@android:/sdcard # echo 3 > /proc/sys/vm/drop_caches
root@android:/sdcard # time cp small/* small2/
1m3.03s real 0m1.05s user 0m9.59s system可以看出差异很明显，Fuse拷贝50M小文件耗费1分钟，而EXT4仅需17s
- Fuse与EXT4性能对比图
2、SDcardFS与Fuse
sdcardfs的作用与fuse相同，也是用于控制文件访问的权限。sdcardfs的工作方式是把内置SD卡目录挂载到用于权限控制目录。对内置SD卡的系统调用，先经过sdcardfs，然后把访问路径改为ext4文件系统的真正路径，再到达ext4文件系统。ext4执行完以后，把结果返回给sdcardfs，再返回给调用者。
对比fuse和sdcardfs，对同一个文件访问，fuse需要经过6次用户态与内核态的切换，但是sdcardfs只需要经过2次切换。另外fuse在内核中有多个队列，队列中元素的出列要等带前面的元素先出列。因此单次文件访问，fuse比sdcardfs需要更多的时间。但是，不管是fuse，还是sdcardfs，对文件的单次访问，大部分情况下时间是很短的，人从感官上无法区分。而对于耗时的文件读写操作的时间来说，上述多出来的时间微不足道。而真正访问时间差异在来源于量变引起质变。当需要进行大量的文件访问时，累积产生时间差异是可以明显感觉出来的。其次需要注意下SDcardfs和Fuse都是大小写不敏感的。SDcard由于减少了用户态与内核态的切换，其理论性能会十分接近真实系统系统。
3、SDcardFS与WrapFS
sdcardfs，是三星wrapfs改写而成。由于关于sdcardfs的介绍较少，简单说明下wrapfs架构，二者之间架构类似。关于WrapFS介绍可参考魅族的内核团队博客
WrapFS 是一种堆栈式文件系统，堆栈式文件系统的一个基本功能就是把操作和参数转换成底层文件系统的操作和参数。这就意味着我们会在 WrapFS 层上创建一个文件对象后会在底层文件对应着创建一个对象，要说明的是，WrapFS 层的这个文件对象只保存在内存里面，断电后会消失，真正文件里面的数据保存在底层文件系统里面。
WrapFS 优势
WrapFS 是一种理想的小模板，可以修改，逐步改造出新的文件系统功能。
WrapFS 可以当作一种方法，用于测试 Linux VFS 超强的堆叠能力。
WrapFS 可以当作学习 VFS，或学习如何写新的 Linux 文件系统的一个好工具。
在 Android 里面，采用的是 FUSE 文件系统，FUSE 文件系统的最终实现是在用户空间，这样导致一个文件操作会两次跨越用户空间和内核空间，导致效率降低，但是 WrapFS 不会有这个问题，其性能接近底层文件系统的实际性能.
WrapFS 与EXT4性能对比图
可以看出其性能已经逼近真实文件系统，这也是谷歌改写wrapfs原因
参考链接：
android sdcard存储方案（基于wrapfs文件系统）
Wrapfs : a stackable file system（一种堆栈式文件系统）
