For UEFI systems, the high-level steps, in theory, are: Right now, the hotness is split image files ( install*.swm ), but that’s a wrinkle we’ll hit as we go. Windows has this habit of changing all the time now - even things like directory structure used in setup. Heck, you can even take your PC image with you as you upgrade machines. It means you can undo mistakes at a level you can’t without a virtual filesystem. It means you can save checkpoints to cloud backup services without the ability of malware to infect ( even backup aware malware ). They make great places to put OS images you can then swap into the active SSD by a simply file copy.
Why in tarnation would you want to boot from a virtual filesystem?īecause large, cheap, and slow spinning disks exist. I’m doing a home gaming rig with a lightweight ML workload, and don’t plan on using this for anything sensitive - so that’s probably the right amount of paranoia for me - but if you’re doing sensitive work, you may want to consider also encrypting the virtual filesystem. For a blend of security and performance reasons, you can choose full disk encryption on your host filesystem ( bitlocker ), but you should probably leave your virtual filesystem clear. You can go down a rabbit hole of virtual machines on the virtualfilesystem if you want - but that’s a performance hit to avoid, esp now that Windows containers are a thing. This is not a VM - no hypervisor involved - purely a virtual filesystem on top of a baremetal host. To compensate, I’ve picked Gen4 NVMe with a big cache ( 7gb/s r/w!!! ), so that the 3% slowdown is immaterial ( because gen4 NVMe is 2x faster than the fastest Gen3, and Gen3 is blazing fast ). Yes, it does slow down the file system ( about 3% ). In a nutshell, you can boot a real, bare-metal host OS from a virtual file system. It sounds so cool, I have to use it to pave my OS for the new PC! I recently got a new PC, and I’ve learned about a feature called “Windows Native Boot”.
0 kommentar(er)
