Gil*_*il' 22
Unix 文件系统传统上是在内核中实现的。FUSE允许用户程序实现文件系统。
内核文件系统更适合用于程序和数据的主文件系统：
- 它们可以在引导介质上使用（实现 FUSE 文件系统的程序必须从某个地方加载）。
- 它们更健壮，因为它们不会因为进程崩溃或被错误杀死而消失。
- 他们要快一些。
FUSE 文件系统还有其他优势，主要围绕其灵活性：
- 它们可以由普通用户加载和挂载，因此它们对于用户倾向于自己挂载的文件系统很方便：用于网络访问，用于浏览存档文件，用于可移动媒体等。
- 如果 FUSE 文件系统驱动程序崩溃，它不会使您的内核恐慌：在访问文件系统的应用程序中，您不会看到比 I/O 错误更糟糕的事情。
- 它们可以非常快速地编程；许多脚本语言都有FUSE 绑定，其中一个有用的 FUSE 文件系统驱动程序可以用几百行代码编写。
- 它们可以非常快速地部署，因为不需要管理员干预来安装它们，并且因为它们可以在受支持的操作系统之间轻松移植。
- 没有与内核静态链接相关的许可问题（这会影响zfs）。
Mic*_*zek 19
如果您指的是真实的磁盘文件系统或任何文件系统，我并不肯定。我从未见过普通的文件系统使用 FUSE，尽管我认为这是可能的；FUSE 的主要好处是它可以让您向应用程序（或用户）呈现一些看起来像文件系统的东西，但实际上只是在用户尝试执行诸如列出目录中的文件或创建新文件时调用应用程序中的函数文件。Plan9以尝试通过文件系统访问所有内容而闻名，而/proc伪文件系统来自于它们；FUSE 是应用程序轻松遵循该模式的一种方式
例如，这是一个（非常无特色的）FUSE 文件系统的屏幕截图，它可以访问 SE 站点数据：
当然，这些文件都不存在；当ls被问及 FUSE 目录中的文件列表时，我的程序中调用了一个函数，该函数向该站点发出 API 请求以加载有关用户 73（我）的信息；cat尝试读取display_name和website_url调用更多从内存中返回缓存数据的函数，而磁盘上没有任何实际存在的数据
- @George 我在弄乱 SO API 时写的。除了 /users 之外，它不使用任何路由，因此您基本上可以在该屏幕截图中看到所有已实现的功能；只是想看看会有多难 (6认同)
- @George 我把它放在 [github](https://github.com/mrozekma/SE-Fuse) (6认同)
- [FAT](http://en.wikipedia.org/wiki/File_Allocation_Table), [NTFS](http://en.wikipedia.org/wiki/NTFS), [iso9660](http:// /en.wikipedia.org/wiki/ISO_9660)、[ext2](http://en.wikipedia.org/wiki/Ext2) 和 [更多](http://sourceforge.net/apps/mediawiki/fuse/ index.php?title=NonNativeFileSystems）。 (4认同)
- 您会发现在 fuse 中实现的重型文件系统：LessFS、GlusterFS、MooseFS。Google 的 GFS（不是 POSIX）也在用户空间中运行。 (2认同)
FUSE 本身并不是真正的文件系统，而是允许将文件系统实现为进程而不是内核模块的代码。
FUSE 最有用的好处之一是允许 GPL 代码与非 GPL 代码“混合”。例如，许多操作系统（如 OpenSolaris 和 *BSD）上的Gnu/Linux 和 ZFS http://zfs-fuse.net/或 NTFS-3G http://www.tuxera.com/community/ntfs-3g-download/
与本机（内核）驱动程序相比，主要缺点是性能影响。