ReactOS has unveiled its Google Summer of Code project, undertaken by Victor Perevertki.
My project is both simple and complicated. I want to add to ReactOS an option to install on and boot from BTRFS partitions. There are a few little things left to implement this:
- BTRFS support in bootloader.
- Fixes in cache controller and memory manager in order to boot with WinBtrfs driver. It is getting better every week, but right now used only with fastfat driver for FAT32.
My primary goal for this internship is implement BTRFS support in FreeLdr – our bootloader.
Another great GSoC project to keep an eye on.
I’m impressed that ReactOs as a project has continued for so long. Honestly, I wouldn’t expect a new file system to be a priority for ReactOs given how much other work is needed to get to a 1.0 release, but it is a neat feature for ReactOS to have anyways. LVM would be useful for me as well, I often wish windows supported it and I lament its absence every time that I install windows.
Edited 2018-06-07 02:34 UTC
ReactOS is already mostly there. I’m actually considering putting it on bare metal soon. I have a tower I don’t use that could be configured for XP era hardware.
It’s always been possible to run it on real hardware. It’s just that it’s never been stable enough to run for longer than a few minutes. I had it installed and booting on a PII Dell back in the early/mid 0.3 days, probably around ’07/’09. It worked well enough to play most of a game of Solitaire.
It’s been my experience hardware support was no where in the vicinity of production ready, and you might get lucky enough for it to boot, but will crash 3-5 minutes later even if you don’t touch anything. I have come under the impression the only people that actually use ReactOS do so in a VM.
ReactOS is probably the weirdest excercise in futility I’ve seen so far. 20 years of hard work and still not stable enough to use, yet still in development. It feels like once it finally reaches semi-usable state it will be completelly useless as NT 4.x base will be too ancient to run anything.
I get it that it’s very difficult to accomplish what they’re trying to accomplish, but with such long timelines it gets pointless.
Edited 2018-06-07 09:33 UTC
ReactOS is currently trying to implement the Windows XP architecture, not NT 4.x. Plus, they have recently started to add compatibility libraries to run software written for Windows 7. So, it will run more modern software.
Point taken though. I am writing this comment from Firefox running on ReactOS ( 4.10-dev ). I cannot use the latest version of Firefox because the latest version does not run on Windows XP ( and I don’t have the compatability stuff mentioned above ).
I love this thread. Its targeting nt 4, no xp, well you’re both wrong, its vista/8/10.
http://www.osnews.com/story/30268/ReactOS_0_4_8_released
It was never a good replacement for any of its targets for my usage. But it keeps on going and keeps on moving the goal posts. I should try it, its been 5-7 years. Its always interesting what does and doesn’t work. Usually my very basic apps crash on start up, and its pretty absurd. But people claim it works for their usage, so I’m probably holding it wrong.
Actually, it kind of makes sense for them to choose BTRFS first. It can still do live migration, replication, and striping, provides better data integrity options than LVM (block checksumming, with automatic self repair when there are valid backup copies), can theoretically provide better compression options than NTFS (though they would have to implement zstandard support in their driver for this to be the case), and provides a snapshot interface that would let them implement a rudimentary version of the Windows VSS API (in a way that’s far more efficient than LVM snapshots, although it would have the problem of not being atomic).
ahferroin7,
I know that ZFS has started the trend of file systems that blur the lines between traditional storage abstractions, but nevertheless I still hold the traditional view that volume management & file systems play different roles.
In practical terms I don’t really mind that windows and linux each has their own specialized file system. But it would be awfully nice if they both supported a common raid and logical volume format; being forced to use archaic static partitions is extremely limiting.
There was a time and place I would have implemented LVM for windows myself, but then microsoft’s geniuses imposed a stupid policy of prohibiting end users from installing their own kernel drivers. Until microsoft reconsiders this stupidity, I’ll never go back to working on the windows kernel. Being dependent upon someone else’s cryptographic signature to run my own code was a bridge too far. Consequently the loss of open source kernel developers like myself has stagnated windows kernel development and ironically has helped propel linux in software development circles.
Edited 2018-06-07 13:27 UTC
FWIW, I’m not necessarily advocating BTRFS in place of LVM. I actually use both on pretty much all of my systems. My intended point was that if they have to choose one, BTRFS provides most of the same features people really care about from LVM, while providing some extra features that are particularly useful to ReactOS.
It’s not entirely ZFS either that has resulted in the blurring of filesystem and volume management tools. The structure of most distributed filesystems looks very similar to ZFS or BTRFS in many respects, and I would say that has contributed just as much to the desire to just have all the logic in one place. I’ve traditionally been of the same opinion as you regarding all of this, but there are some very distinct advantages to having them be tightly integrated (for example, snapshotting at the VFS level is often easier, safer, and saner than doing so at the block level).
As far as Windows support for LVM, there’s exactly zero benefit for Microsoft in doing that, given that they have their own solutions (LDM and more recently Storage Spaces). Yeah, it would be nice if everybody could use the same storage format, but standardizing like that would require everybody to agree on new features too, which is damn near impossible.
“I still hold the traditional view that volume management & file systems play different roles.”
If you’ve used ZFS then you will have still found that clear divide between the two. The zpool command handles volume management and the zfs command handles file system level stuff. People tend to refer to the two together as ZFS for simplificty, but it’s really two separate tools.
jessesmith,
Yes there’s a large amount of overlap between ZFS pools and LVM. I’m sure you are already aware that there are many competing solutions.
Linux LVM
Sun ZFS pools
Apple CoreStorage
Microsoft Storage spaces
…
https://en.wikipedia.org/wiki/Logical_volume_management
I think we can all agree that logical volumes are a huge improvement over static partitions. While I’ve put LVM to very good use, I’m not so attached to it that I wouldn’t switch to something else to get the benefits of shared volumes across operating systems. Yet that’s the problem, all these competing solutions makes it all that much harder to actually use logical volumes effectively in a multiboot environment. Despite the obvious benefits of logical volumes, to this day I’m still statically reserving arbitrary amounts of space for operating systems I might want to install alongside each other and I find it extremely frustrating that I cannot manage 100% of the disk using logical volume management tools.
Edited 2018-06-07 22:20 UTC
Why would this be necessary when ReactOS should probably be booting from UEFI?
UEFI requires a FAT formatted EFI System Partition. The boot files are placed in there. If you needed more boot files then a btrfs EFI driver could be in there too.
Once the operating system is running it has its own btrfs drivers.