njc*_*njc 3 ssd vmware-player windows-xp
我知道以前也有人问过类似的问题，有很多关于在 SSD 上安装 Windows XP 的信息。
我可以理解，Windows XP 不是为 SSD 设计的，好吧，它是在 SSD 之前发布的，所以没有修剪功能，并且 XP 向磁盘提交了大量写入。
经过所有这些搜索和阅读，我明白为什么 Windows XP 不应该安装在 SSD 上。虽然有些人声称SSD有这么多写入周期没关系，但我不太相信这一点。
说到点子上了。我读过一篇博客，声称如果您的操作系统支持修剪（现在他们都支持修剪），您可以将 Windows XP 安装为虚拟机来宾。事情就到此为止了，他们没有详细说明这一点。所以我想问一下，这是真的吗？
或者最好找到一个 2.5 英寸硬盘，将其连接到我的主板上，然后将 Windows XP 客户机指向该硬盘？
万一有人想知道为什么。我正在做一项在 Excel 2010 中构建的工作 - VBA 密集型（是的，很多年前构建的），并且大部分 VBA 代码调用基于 Windows XP Pro 构建的 Win32 API。
如果您的操作系统支持修剪（现在几乎都支持修剪），您可以将 Windows XP 安装为虚拟机来宾
我想说这主要是一个错误的说法（我的意思是 TRIM 将由在 VM 磁盘映像上完成的文件删除触发）。某些虚拟机管理程序可能会将完全归零的写入块转换为 TRIM 命令，但文件删除通常不会触发归零（而只是文件系统元数据中的修改）。此外，这种翻译需要主机操作系统的支持。（我认为 Linux 上的 qemu 是可能的，因为您可以使用 Fallocate 在文件上触发部分 TRIM，但我不太确定 Windows 在其块层中是否有类似的设施。）
不过，我想说不要太担心 TRIM。借助现代 SSD 中的磨损均衡机制，TRIM 可能并不像许多人想象的那么重要/关键。
特别是对于您的情况，在主机系统上启用 TRIM 应确保始终有大量未映射的存储，除非它确实已满。因此，即使对于虚拟机完成的写入，磨损均衡也会生效。换句话说，即使通过映射的 LBA 进行覆盖也不应导致在幕后对同一内存进行就地写入。（当 LBA 映射到其他内存时，映射的旧内存将被垃圾收集，因为显然其上的数据不再被视为“有用”，这就是为什么您并不真正需要 TRIM 来进行所有覆盖。什么你真正需要的是有一个未映射的内存池，可以让磨损均衡发挥作用。）
如果您为虚拟机使用专用驱动器（无论是否采用直通方式），您可能需要考虑过度配置 - 确保一堆 LBA 未映射并且永远不会被映射。这可以通过创建一个保持未格式化和修剪的分区来完成。（您可以提前修剪整个驱动器，也可以只修剪该分区（如果它是通过缩小现有分区获得的空间创建的）。这可以blkdiscard在 Linux 上完成。不过，请确保在正确的驱动器/分区上运行它，因为它将擦除其上的数据。）（我不知道到底多少才算足够，但除非空间非常紧张，否则只需给它几 GB。）
话虽如此，有传言称大多数驱动器都在幕后实施了过度配置，因此可能根本没有必要自己进一步保留一些未映射的空间。