原型设计一个文件系统
制作文件系统原型时有哪些最佳实践？
我之前尝试过用Python和fusepy，现在我很好奇：
- 从长远来看，任何靠谱的文件系统实现都应该用C语言吗？如果不使用C，会影响可移植性吗？或者最终会导致性能问题吗？
- 还有其他类似FUSE的实现吗？
- 显然，核心文件系统技术发展得很慢（像fat32、ext3、ntfs这些是大头，其他的都是小角色），那在调试时通常会用哪些技巧呢？
- 一般来说，文件系统开发是如何进行的，才能达到在主要操作系统中高度优化和完全支持的实现呢？
4 个回答
我建议你为内核块设备的API层创建一个模拟对象。这个模拟层应该使用一个通过mmap映射的文件作为文件系统的存储后端。这样做有很多好处：
- 运行单元测试时，文件系统的性能非常快。
- 可以在模拟层中插入调试代码或断点，以检查是否出现错误。
- 可以轻松保存多个文件系统状态的副本，方便研究或运行测试。
- 可以有计划地引入块设备错误或其他系统事件，让文件系统进行处理。
用户空间中的文件系统（无论是在FUSE中还是Mac版本中）确实非常方便，但它的性能不会像传统的内核空间文件系统那样好（而且传统文件系统必须用C语言编写）。可以说，这就是为什么微内核系统（文件系统和其他功能都在用户空间中）从来没有真正“把单体内核甩在身后”的原因。A. Tanenbaum在近二十年前在Minix邮件列表上攻击Linux时，曾自信地说过这句话（作为计算机科学教授，他表示如果Linus选择单体架构来做操作系统，他会给Linus不及格——当然，Linus对此回应得很激烈，这段对话现在非常有名，网上有很多地方可以找到）。
可移植性其实不是个大问题，除非你是针对内存非常有限的“嵌入式”设备——除了这种设备外，你可以在任何可以运行C的地方运行Python（如果有什么限制，那就是FUSE的可用性，而不是Python运行环境的可用性）。不过，性能确实可能会是个问题。
从长远来看，任何值得尊敬的文件系统实现都应该用C语言写吗？如果不使用C语言，会不会影响可移植性，或者最终导致性能问题呢？
不一定，实际上有很多性能优秀的语言并不是C，比如O'Caml和C++。事实上，我认为NTFS应该是用C++写的。不过，你似乎是从Linux背景来的，而Linux内核是用C写的，所以任何想要合并到内核中的文件系统也必须用C来写。
还有其他类似FUSE的实现吗？
在Windows上有几个类似的实现，比如http://code.google.com/p/winflux/和http://dokan-dev.net/en/，它们的成熟度各不相同。
显然，核心文件系统技术发展得很慢（像fat32、ext3、ntfs，其他的都不算什么），那么在调试方面通常使用什么技术呢？
这在Windows上大多是对的，在Solaris上有ZFS，在Linux上有ext4和btrfs。调试技术通常涉及在各种操作中间关掉机器，看看数据处于什么状态，存储大量数据并观察性能。
一般来说，文件系统开发的过程是怎样的，才能在主要操作系统中实现高度优化和全面支持的版本呢？
这又要看具体哪个操作系统，但通常需要进行大量测试，特别是要确保在出现故障时不会丢失数据。