On Thu, Aug 14, 2014 at 8:05 AM, Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> wrote: > The fact that it is Windows using NTFS is probably part of the problem. > Here's some things you can do to decrease it's background disk > utilization (these also improve performance on real hardware): > 1. Disable system restore points. These aren't really necessary if you > are running in a VM and can take snapshots from the host OS. Great point - doing that. > 2. Disable the indexing service. This does a lot of background disk IO, > and most people don't need the high speed search functionality. Being a developer, while I usually don't need this functionality, when I /do/ need it, I need it /right now/. > 3. Turn off Windows Features that you don't need. This won't help disk > utilization much, but can greatly improve overall system performance. Normal for me, so it's already done. Well, except for #1 above. ;) > 4. Disable the paging file. Windows does a lot of unnecessary > background paging, which can cause lots of unneeded disk IO. Be careful > doing this however, as it may cause problems for memory hungry applications. The VM is getting 16G, so I see no reason to keep a large paging file, so good call her as well. However, I have had some disk-related BSODs which produced some MEMORY.DMP files I was planning to investigate if all external troubleshooting paths were exhausted, I wouldn't have been able to capture those if I had a minimal page file. Also, I would need to once again increase the page file if I wanted to create a NMI-based crash dump. > 5. See if you can disable boot time services you don't need. Bluetooth, > SmartCard, and Adaptive Screen Brightness are all things you probably > don't need in a VM environment. Done as a matter of course. > > Of these, 1, 2, and 4 will probably help the most. The other thing is > that NTFS is a journaling file system, and putting a journaled file > system image on a COW backing store will always cause some degree of > thrashing, because the same few hundred MB of the disk get rewritten > over and over again, and the only way to work around that on BTRFS is to > make the file NOCOW, AND preallocate the entire file in one operation > (use the fallocate command from util-linux to do this). I've been working through this for long enough, I've done both QEMU preallocate and fallocate. The current image is large enough, that I just set the nocow attr on the target directory and copied the preallocated qcow2 image from a usb drive... thus it wasn't fallocate'd. I'm again hitting my ignorance threshold, so am unclear whether fallocate will behave the same as a copy from usb/ext4 to my btrfs subvolume. -rb -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
