Disclaimer: this was originally written as a reply to a topic on the ReactOS boards, regarding the GSoC projet that targets at booting ReactOS from BtrFS volume. This was an opportunity to give more details about the file systems situation in ReactOS, as it is often discussed among the community. One of the common question being: why do we have BtrFS and not NTFS? You’ll find the answer here!
I often read on boards people having strong opinions about file systems situation in ReactOS. About current situation, about ideal situation, about future situation.
So, let me try to clarify once for all current file systems situation, current goals, what are the under going works. In short: WHY is it that way and not another way. You’ll understand better why this GSoC project makes sense, not only to (attempt to) gain a new ReactOS developer, but also to improve our project.
Historically, from users point of view, ReactOS had two file systems: CDFS & vFAT. Both having their dedicated drivers. These drivers have been developed in ReactOS, against the ReactOS kernel and our libs. These drivers weren’t working in Windows and Windows drivers were not working in ReactOS. Both ReactOS drivers and ReactOS kernel have been made to work together. Our drivers need our kernel, and our kernel needs our drivers. This is clearly not the best way to improve ReactOS compatibility nor to make it progress.
There has been an attempt a few years ago (or perhaps a decade ago?) to develop a new FAT driver, in W2K3, using an external lib, and to fix ReactOS around so that we would be closer to what Windows kernel does. Unfortunately, because ReactOS is a FOSS project, the developer attention got drawn elsewhere and this driver got abandoned and then dropped. Our kernel didn’t benefit from the attempt.
In parallel, several developers were doing their best to improve our vFAT driver (which even became a FastFAT driver in the process ), but still against ReactOS, which didn’t help regarding compatibility.
Some did the test, and just took the drivers from Windows 2003 and put them in ReactOS, it just BSOD and didn’t work.
So, how to improve compatibility ? Make our drivers work in Windows 2003, or make drivers that work in W2K3 work in ReactOS. First option is no go for me. I have no way to instrument a W2K3 (reminder, I develop on Linux ) to have proper debug, so, only remains the second option.
We could have used MS drivers for this. As FSD implementation samples, MS provides CDFS and FastFAT driver. But two problems raise: first one is a half driver (only RO), and second is really complex. Hence, they are good examples, but not that easy to debug.
Then comes 3rd party drivers: ext2fsd, winbtrfs, and so on. These work on Windows 2003 (or nearly ) and can provide good test case. And this is the choice I made. Getting these in ReactOS. It has two benefits: providing live test cases for our kernel and bringing in new features. Sounds great, isn’t it? And it worked. We brought support for these FS, but we also squashed a number of bugs in our kernel at each release of these drivers breaking in ReactOS. Our kernel started working better. For the record, Trevor Thompson, a GSoC student, even helped on a part.
Thanks to these efforts, we came to the point where we could drop our own CDFS implementation in favor of the Microsoft one. It just works out of the box (or nearly ) in ReactOS.
Nowadays, our kernel isn’t still ready to handle setup with MS FastFAT, but could work once installed with it. At some point, ext2fsd and MS FastFAT seem to expose the same issues when it comes to setup. Fixing one should help the second one. BtrFS could be already used to install ReactOS. It requires less fixing, and less complicated fixing, no on-disk corruption, no broken behavior in the kernel. It is then more interesting for a student to work on it and bring ReactOS on it; while being less frustrating for the student, and more relevant for the community as regular progress can be shown. It will pave the way for fixing the other FSDs. Every single bit added in the right direction is a plus for any FSD. It’s definitely not wasted time. And it will also help ReactOS in general: there are software, features, APIs we cannot test because FAT is a too limited file system (for instance, no hard links). Having BtrFS setup will allow testing these code paths without requiring second hard drive and so on.
Now that’s said, what about NTFS? NTFS support in ReactOS is a complex topic. It was the first thing I worked on when I joined ReactOS (remember, in 2007 ), then I moved to other topics. I later came back to it, and brought it to a level were it could read from any NTFS partition (or nearly ). We had the chance to have a student working on it for two GSoCs: Trevor Thompson. He even brought in initial write support. Unfortunately, our NTFS driver development started along with vFAT and CDFS drivers and suffers from the same issues. It is really ReactOS specific. I understand NTFS is important for ReactOS, but it requires hard work to complete, and waiting for it to fix our kernel compatibility would be a mistake that would make the project stay behind. So, it will come, one day. It just needs more time to mature. And no, NTFS-3G is no use here (nearly ). It is a usermode implementation for FUSE that cannot be just translated in our kernel. And no, you don’t want to install ReactOS on our NTFS driver, it would be slow as hell, it doesn’t support any caching, yet.
I hope you understand better what’s going on regarding file systems in ReactOS and will be less prone to say this GSoC slot is misused .