Hydranix

Not really-really, a RAW (or non-native VHD) booting actually has the disk drive image mapped BEFORE the bootloader gets control and is "hooked" by the suitable driver (say Firadisk or WinVblock) just like a "real" hard disk is "hooked" by the controller driver. As a matter of fact a "fixed" VHD is ALREADY a RAW image (with a sector appended to it). Which BTW does not mean that hibernate work (or does not work) with RAW image booting. Which actually (the header for monolithic, fixed, non-sparse, non-growing non-differential VHD's) is NOT a header but rather a footer, i.e. a single sector "appended" to the RAW image, JFYI: http://reboot.pro/topic/9715-firadisk-and-vhd-img-images/?p=83781 http://reboot.pro/topic/8480-clonedisk/ jaclaz This is a very late response but I just now first read the reply... At the time of my post, I was fully aware of those drivers, and had used them many times. The thing is, you can essentially write a driver to extend the functionality of Windows in most any way. But using grub4dos to load the file into memory before the Windows bootloader is invoked is bound 3rd party (pre)bootloaders and 3rd party drivers. True though, I should have said footer instead on header.

You can't block telemetry with the hosts file. Microsoft's telemtry software andcomponents make use of DNS_QUERY_NO_HOSTS_FILE NTLite likely does a good job of removing it though I wouldn't know because of the expensive licesning even for personal / non professional use...

Maybe I can help you out. Hibernating from anything except the physical hard drive isn't exactly impossible, however with Windows there is no way for to happen. This is due to how hibernating and Windows works. Hiberating a computer is the equivalent of taking everything on the system's RAM and saving it to a file on the hard drive. When you resume from hibernate, this file must be completely loaded into RAM at a very early stage in the boot process. So early in fact, that the computer doesn't have any understanding of VHD files or how to access them. It can only read a whole file from disk into memory. (it reams the hibernate file). It isn't possible with raw disk images either becuase Windows has no way of knowing where the hibernate file resides when you boot from what is initially the same general concept as VHD boot. Normal sleep, or Suspend-to-RAM should work just fine on any kind of boot however. As for creating a raw disk image, a VHD (not sure about VHDX) can be stripped of its VHD header and become a raw disk image. Though it will probably not boot, if you set up Windows to VHD boot on the OS from within the image, and then tried to boot it as a raw disk image after stripping the header. The other way to create a raw disk image is to create a byte-for-byte image of a hard disk, by directly reading the partition to a file. This can be easily accomplished from OS X by using the 'dd' command as the root user, and copying the partition you want to make into a raw image to a file residing on a partition which grub4dos can access (not HFS+) For your needs, coupled with your level of technical expertise, I'd say you'd want to stay away from raw disk images. Try perhaps, a virtual machine. If you must boot natively, then I'd stick with the current VHD boot situation you've set up.

You stated that you simply formatted your OS partition. (I'm assuming you used Window's tools, included in the installation ISO/DVD. Correct me if I'm wrong) Do you use a hardware RAID controller, or is it a "fakeraid"? If hardware, does it have it's own memory banks? I know this isn't the cause, but it's worth looking into.. Are your partitions aligned properly, and is the stripe size optimal for the disks erase block size? You stated you left your boot partition intact between OS benchmarks. This indicates that you didn't do a low level erase on each disk in the array and rebuild it. Without releasing the charges in the NAND cells, it must be done at the time of the write, thus causing several nano seconds of delay multiplied by the millions(?) of cells. (this is completely subject to different disk firmwares, which are industry secrets so nobody can know what takes place, so let's assume the worst) Perhaps the disks aren't/weren't TRIMed adequately before each benchmark, and during normal usage. Check into your system's garbage collection implementation and see what controls it between the two OSes (Windows, RAID controller, disk firmware, etc). I know on my PCIe SSD fakeRAID-0 RevoDrive, there's no way for me to actually instruct Windows to perform TRIM, however Linux does it quite easily. Strange..? Thats all I got for now, thanks for starting this thread, I learned a few quick tricks to boost my systems performance. -HNx