文件系统原型设计
文件系统原型设计的最佳实践有哪些？
我在 Python 中尝试使用 fusepy，现在我很好奇
- ：从长远来看，如果有任何 值得尊敬的文件系统实现 是C语言吗？不会参加 C 篮 可移植性，或最终导致 性能问题？
- 是否还有其他实现，例如 保险丝？
- 显然核心文件系统技术进展缓慢（fat32、ext3、ntfs，其他都是小鱼），采用了哪些调试技术？
- 为了在主要操作系统中实现高度优化、完全支持的实现，文件系统开发的一般过程是什么？
What are some best practises for prototyping a filesystem?
I've had an attempt in Python using fusepy, and now I'm curious:
- In the long run, should any
respectable filesystem implementation
be in C? Will not being in C hamper
portability, or eventually cause
performance issues? - Are there other implementations like
FUSE? - Evidently core filesystem technology moves slowly (fat32, ext3, ntfs, everything else is small fish), what debugging techniques are employed?
- What is the general course filesystem development takes in arriving at a highly optimized, fully supported implementation in major OSs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
存在于用户空间中的文件系统（无论是在 FUSE 或其 Mac 版本中）确实是一件非常方便的事情，但不会具有与存在于内核空间中的传统文件系统相同的性能（因此必须使用 C 语言）。你可以说这就是微内核系统（文件系统和其他东西存在于用户空间中）从未真正“将整体内核抛在尘埃中”的原因，正如 A. Tanenbaum 在 Minix 邮件列表上的一篇著名帖子中攻击 Linux 时所肯定地说的那样二十年前（作为一名计算机科学教授，他说他会因为为自己的操作系统选择单一架构而让 Linus 失败——Linus 当然做出了积极的回应，整个交流现在非常有名，可以在网络上的很多地方找到） ;-)。
可移植性并不是真正的问题，除非您的目标是内存量非常有限的“嵌入式”设备——除了此类设备之外，您可以在可以运行 C 的地方运行 Python（如果有的话，那就是 FUSE 的可用性将限制你，而不是Python运行时）。但性能绝对可以。
A filesystem that lives in userspace (be that in FUSE or the Mac version thereof) is a very handy thing indeed, but will not have the same performance as a traditional one that lives in kernel space (and thus must be in C). You could say that's the reason that microkernel systems (where filesystems and other things live in userspace) never really "left monolithic kernels in the dust" as A. Tanenbaum so assuredly stated when he attacked Linux in a famous posting on the Minix mailing list almost twenty years ago (as a CS professor, he said he'd fail Linus for choosing a monolithic architecture for his OS -- Linus of course responded spiritedly, and the whole exchange is now pretty famous and can be found in many spots on the web;-).
Portability's not really a problem, unless perhaps you're targeting "embedded" devices with very limited amounts of memory -- with the exception of such devices, you can run Python where you can run C (if anything it's the availability of FUSE that will limit you, not that of a Python runtime). But performance could definitely be.
不一定，有很多不同于 C 的执行语言（O'Caml、C++ 是第一个想到的）。事实上，我希望 NTFS 是用 C++ 编写的。问题是你似乎来自 Linux 背景，并且由于 Linux 内核是用 C 编写的，任何希望合并到内核中的文件系统也必须用 C 编写。
有几个适用于 Windows 的工具，例如 http://code.google.com/p/winflux / 和 http://dokan-dev.net/en/ 的不同成熟度级别
再说一次，这在 Windows 中基本上是正确的，在 Solaris 中你有 ZFS，在 Linux 中ext4 和 btrfs 存在。调试技术通常涉及在各种操作中间关闭机器并查看数据的剩余状态，存储大量数据并查看性能。
同样，这取决于哪个操作系统，但它确实涉及大量测试，尤其是
确保故障不会丢失数据。
Not necessarily, there are plenty of performing languages different to C (O'Caml, C++ are the first that come to mind.) In fact, I expect NTFS to be written in C++. Thing is you seem to come from a Linux background, and as the Linux kernel is written in C, any filesystem with hopes to be merged into the kernel has to be written in C as well.
There are a couple for Windows, for example, http://code.google.com/p/winflux/ and http://dokan-dev.net/en/ in various maturity levels
Again, that is mostly true in Windows, in Solaris you have ZFS, and in Linux ext4 and btrfs exist. Debugging techniques usually involve turning machines off in the middle of various operations and see in what state data is left, storing huge amounts of data and see performance.
Again, this depends on which OS, but it does involve a fair amount of testing, especially
making sure that failures do not lose data.
我建议您为内核块设备 API 层创建一个 模拟对象。模拟层应使用
mmap文件作为文件系统的后备存储。这样做有很多好处：I recommend you create a mock object for the kernel block device API layer. The mock layer should use a
mmap'd file as a backing store for the file system. There are a lot of benefits for doing this:受人尊敬的文件系统将是快速且高效的。对于 Linux，这基本上意味着用 C 语言编写，因为如果你不随内核一起分发，你就不会被认真对待。
至于 Fuse 等其他工具，有 MacFUSE，它允许您使用相同的代码在 Mac 和 Linux 上。
Respectable filesystems will be fast and efficient. For Linux, that will basically mean writing in C, because you won't be taken seriously if you're not distributed with the kernel.
As for other tools like Fuse, There's MacFUSE, which will allow you to use the same code on macs as well as linux.