Ntfs2btrfs is a tool which does in-place conversion of Microsoft’s NTFS filesystem to the open-source filesystem Btrfs, much as
↫ Mark Harmstonebtrfs-convertdoes for ext2. The original image is saved as a reflink copy atimage/ntfs.img, and if you want to keep the conversion you can delete this to free up space.
An amazing piece of software that works on both Linux and Windows, and even, as described above, comes with the option of undoing the conversion if you so desire and haven’t removed the original image yet. Its developer, Mark Harmstone, of course stresses that while he thinks the tool is quite stable, he obviously makes no guarantees or claims about its stability. In other words, please don’t use this on sensitive data or in a production environment.
What makes this tool even more amazing is that you can combine it with two of Harmstone’s other tools to really pull some rabbits out of your hat. First, there’s his Btrfs driver for Windows, which, as the name implies, allows Windows to work with Btrfs-formatted drives. Second, and here’s where things get really spicy, there’s Quibble, his custom bootloader consisting of open source reimplementations of Windows’ own bootloader. Using these three tools together you can, if you’re lucky, boot and run Windows off a Btrfs drive.
That’s quite cool, and while perhaps not particularly useful due to its experimental nature, it’s still an awesome weekend project.
Cool beans. I find Microsoft’s bootloader inferior. to those on linux, at least in terms of features.
If the author shows up by chance: The FAQ doesn’t mention secure boot, but it’s one of the first questions that came to mind.
I assume you have to disable secure boot in windows? Do you handle secure boot at all?
I wrote a couple boot-loaders in the day (before UEFI). It’s not hard at all, At least for DOS devs calling BIOS interrupts is second nature 🙂
The first time I tried Linux it was in a DOS (Windows 95?) computer. Slackware with UMSDOS filesystem. No need to deal with repartitioning the disk that I couldn’t do because I wasn’t the only one using that computer. Linux was just installed in a directory in a FAT partition.
Without that I wouldn’t have dared to try. Nowadays it’s easier to test things with virtual machines.
LOL, this is the type of useless waste that happens when you let software engineers run wild without direction. His time, effort and energy would have been better spent on, you know, maybe modernizing/fixing the UNIX/Linux filesystem permissions (yes I know ACL’s exists, but no one uses them, and that’s exactly what I mean).
tuaris,
Better for you doesn’t necessarily mean better for the dev. Do you agree that what developers do on their own time is their own prerogative? I’m sure there’s lots of stuff I like to do that doesn’t mean much to other people 🙂
And I would not call this completely useless.
The “Windows New File Systems” (ReFS) never actually materialized. It would be the answer to modern reliability requirement like ZFS and BTRFS. And they only support it on the server today (as far as I know).
That makes BTRFS an excellent choice for Windows desktops, if it becomes easy and reliable enough.
And as you mentioned, secure boot is also important.
sukru,
BTRFS is a nice modern FS and for most users running single disk file systems I think it’s fine.
I’d really like to use it myself and I absolutely love the way it dynamically handles re-balancing! So awesome! However every time I revisit it in order to take advantage of the improvements over LVM+extfs I come across the same major problems over and over again. First of all raid 5/6 are still not officially stable yet, but even avoiding those BTRFS raid only offers data redundancy, but not operational redundancy.
Every other raid solution increases fault tolerance as you add redundant disks, such as RAID 6 able to handle double disk faults before risking failure. However many users are surprised to learn that it’s the opposite with BTRFS’s implementation: every disk you add to the raid you actually decreases the system’s fault tolerance. If you have four or five disks in your raid, you significantly increase the chances of a boot failure since a failure of any one of them will prevent booting 🙁
Unfortunately the devs don’t seem to care about bootup exceptions because from their perspective it’s a “feature” that lets them manually control recovery. But for production and other situations where downtime is undesirable this absolutely must be automatic! Until BTRFS fixes this, it’s unfit for purpose next to other raid solutions.
It’s technically possible to run BTRFS on top of another raid implementation like mdraid, but then you loose out of some of BTRFS’s benefits like rebalancing across different sized disks and FS integrity protection. BTRFS has strong selling points for me, but it’s not worth switching to BTRFS until they fix these raid issues….I don’t know if they will though. I’d contemplate writing my own if I could justify the effort, haha.
I agree, it’s a stupid (or ideological) decision.
But you can change in the file /etc/grub.d/10_linux (Ubuntu) the line
RUB_CMDLINE_LINUX=”rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}”
into
GRUB_CMDLINE_LINUX=”rootflags=degraded,subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}”.
Then the system will boot, even if the mirror is degraded.
AnAmigian,
BTRFS has a genuinely great feature-set. Really I’m sold, but this has to be fixed!
Yeah, I’ve looked for workarounds like this, but IIRC it is officially unsupported for two reasons.
1) Administratively degraded boot, while permitting boot with missing disks, doesn’t touch the raid configuration and can therefor cause data loss if the missing disk returns on a subsequent boot. I’d agree this posses a serious risk. So it needs to be fixed rather than leaving users to sort it out manually..
2) BTRFS lacks a feature that allows other raids to handle the above situation very well, which is a write map. If an active member goes missing and comes back, other raid implementations can use write maps to resync the member to a current state without completely rebuilding it. This feature is not critical to safe and reliable RAID operation, but it would be nice for BTRFS to achieve feature parity with mdraid.
I tested BTRFS again a few weeks ago because I’d really like to use it in my builds, but it’s so important to me to have a raid solution that protects against downtime. Every other raid solution I’ve ever used provides redundancy out of the box without any manual intervention. BTRFS don’t seem to respect the fact that manual intervention is downtime and potentially very significant downtime if you have a colocated server.. And it can be very inconvenient if you have to lug around a monitor and keyboard to investigate boot errors on a normally headless machine. Unfortunately BTRFS fails hard here as a raid solution….I’m so frustrated that the devs don’t care.
BTW, the reason I’m so attached to the subject is because I’m in the process of updating the custom linux distro I run on my own machines. I standardized on mdraid + lvm + extfs a long time ago but now I have to decide what to do over the next several years. On the plus side it works and has been robust. Disk failures have been mitigated perfectly as expected. On the minus side, it’s antiquated and the tools can be a bit cumbersome. LVM2 thin volumes were kind of hacked into LVM. Snapshots work, but because LVM and FS are separate layers extra care has to be taken to freeze the FS before snapshotting, etc.
BTRFS would be a welcome upgrade for modernization. But as it doesn’t pass the raid requirements. I’m left contemplating whether to go with a piecemeal approach like mdraid + BTRFS. The thing is I also use LVM to provide subvolumes for virtual machines, which BTRFS doesn’t support.
LVM handles “trim” operations from the guest, I don’t know if VM trim operations would propagate up to BTRFS files, which I need for thinly provisioned VMs. I had decided against hosting VM images inside of a file system many years ago because I found that routine fsck operations on massive host volumes took ages to complete. LVM volumes offered the solution. This is TBD with BTRFS.
If it came down to it, I could go with mdraid + LVM + btrfs, but at that point it’s not really worth it to me. These are the points I’ve been debating with myself, haha.
ACLs are rarely used because for 99.9% of use cases the existing permissions are “good enough”…
For the core OS binaries you want them readable by all users and only writable by root.
Sensitive files like shadow you only want readable by root.
User files you only want readable by the user who owns them.
The use cases where you benefit from ACLs rather than suffering from the extra complexity are very niche.
Why do you think it is wrong for someone to follow its curiosity? Economy is not an end. Happiness is my goal and curiosity is my guide.
unfortunately, I would take caution with these, as NTFS2BTRFS hasn’t been updated since March 2023, Quibble hasn’t since May 2023, and WinBTRFS since May 2024. is Mark still working on any of this?
You are looking at the releases. If you look at the commits, which is what shows if the project is actively being developed:
– ntfs2btrfs was last updated 4 days ago
– the BTRFS driver was updated last month
– quibble was updated 6 months ago
Pretty sure ReactOS can boot off BTRFS. I believe it’s the interim filesystem between the limited FAT32 and the end goal of booting from NTFS. BTRFs provides a lot of NTFS like features without the hassle of writing drivers (as is mentioned here, they already exist) or reverse engineering proprietary ones.
Theoretically ReactOS aims to be kernel level compatible, so you should be able to load and use existing drivers at least until they can be replaced with open source ones.