我知道以前也有人问过类似的问题,有很多关于在 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。
我想说这主要是一个错误的说法(我的意思是 TRIM 将由在 VM 磁盘映像上完成的文件删除触发)。某些虚拟机管理程序可能会将完全归零的写入块转换为 TRIM 命令,但文件删除通常不会触发归零(而只是文件系统元数据中的修改)。此外,这种翻译需要主机操作系统的支持。(我认为 Linux 上的 qemu 是可能的,因为您可以使用 Fallocate 在文件上触发部分 TRIM,但我不太确定 Windows 在其块层中是否有类似的设施。)
不过,我想说不要太担心 TRIM。借助现代 SSD 中的磨损均衡机制,TRIM 可能并不像许多人想象的那么重要/关键。
特别是对于您的情况,在主机系统上启用 TRIM 应确保始终有大量未映射的存储,除非它确实已满。因此,即使对于虚拟机完成的写入,磨损均衡也会生效。换句话说,即使通过映射的 LBA 进行覆盖也不应导致在幕后对同一内存进行就地写入。(当 LBA 映射到其他内存时,映射的旧内存将被垃圾收集,因为显然其上的数据不再被视为“有用”,这就是为什么您并不真正需要 TRIM 来进行所有覆盖。什么你真正需要的是有一个未映射的内存池,可以让磨损均衡发挥作用。)
如果您为虚拟机使用专用驱动器(无论是否采用直通方式),您可能需要考虑过度配置 - 确保一堆 LBA 未映射并且永远不会被映射。这可以通过创建一个保持未格式化和修剪的分区来完成。(您可以提前修剪整个驱动器,也可以只修剪该分区(如果它是通过缩小现有分区获得的空间创建的)。这可以在
blkdiscard
Linux 上完成。不过,请确保在正确的驱动器/分区上运行它,因为它将擦除其上的数据。)(我不知道到底多少才算足够,但除非空间非常紧张,否则只需给它几 GB。)话虽如此,有传言称大多数驱动器都在幕后实施了过度配置,因此可能根本没有必要自己进一步保留一些未映射的空间。
这取决于您的虚拟磁盘配置。
如果您使用的是由 SSD 中的文件支持的虚拟磁盘映像,即使主机操作系统支持 TRIM,问题是磁盘映像仍然会被视为脏的。从主机系统的角度来看,磁盘扇区仍然被客户系统占用。因此,如果来宾操作系统不支持 TRIM,则在删除来宾操作系统上的文件时,磁盘映像不会缩小。
主机系统将 TRIM 覆盖的扇区,但主机系统不知道要 TRIM 客户机未 TRIM 的脏块。
如果您的虚拟磁盘设置为 IDE/SATA 直通,则主机操作系统不会以任何方式干扰该接口。来宾操作系统将负责任何需要完成的调整。
SSD 会磨损。无论如何,SSD 都会进行磨损均衡。TRIM 只是减少磨损并使磨损均衡更有效的一种手段。TRIM 只是一种方法,过度配置是另一种方法。如果我们需要使用非修剪操作系统,我们可以通过预留更多的过度配置空间来在一定程度上进行补偿。
问题是,SSD 需要“空闲块”来存储新数据。IOW 想象 LBA 1000 保留文件的一部分,您更新文件,现在 SSD 必须为 LBA 1000 找到一个新位置。它通过找到一个空闲位置、在那里写入新数据并“映射”该位置来实现这一点到 LBA 1000。它现在知道之前映射到 LBA 1000 的点可以被擦除,因此它成为未来数据可用的空闲点的一部分。
修剪
现在假设我们删除占用 LBA 1000 的文件。这是操作系统/文件系统级别的操作,SSD 无法知道它现在可以删除映射到 LBA 1000 的位置。这就是 TRIM 的用武之地。TRIM 是一个“命令”,允许操作系统告诉 SSD“我已经完成了 LBA 1000”,因此 SSD 现在可以主动准备分配给 LBA 1000 的位置以供将来的数据使用。
无修剪
如果没有 TRIM,SSD“知道”映射到 LBA 1000 的位置的数据发生了什么情况的唯一方法是我们再次写入它。因此,在 Windows 中,您创建一个新文件,它最终会被写入 LBA 1000,就操作系统而言,该文件是空闲的(映射到 LBA 1000 的簇是空闲的)。由于我们写入新数据,SSD 会将新位置映射到 LBA 1000,而之前的位置现在可用于垃圾收集器,垃圾收集器将擦除它并使其可用于将来的数据。
无 TRIM 方法本身不存在根本问题。然而,缺少 TRIM 会给我们留下一堆操作系统知道可用而 SSD 不可用的位置。
问题
这可能会成为一个问题:SSD 不能仅仅擦除我们迄今为止所称的斑点。它只能同时擦除属于同一擦除块的一堆点。
因此,可能会发生 LBA 1000 处的位置被丢弃的情况,因为操作系统删除了该位置处的数据,而 LBA 1001 处的位置没有删除。如果两个点碰巧位于同一擦除块中,则 LBA 1001 包含有效数据而 LBA 1000 不包含有效数据,这会阻止 LBA 1000 被擦除。SSD 首先必须将数据从 LBA 1001 移动到不同的位置。
IOW SSD 需要空间“呼吸”、重新整理数据、合并已使用的位置以及未使用的位置,以便它可以擦除后者并为新数据做好准备。喘息空间越少,SSD 就越需要重新洗牌以整合空闲擦除块和正在使用的擦除块。洗牌越多,磨损就越多。
过度配置
TRIM 是为 SSD 提供喘息空间的一种手段,超额配置是另一种手段。过度配置仅仅意味着预留大量位置。如果我们有 1000 个 LBA 名额,并且留出其中的 10%,那么我们将始终有 10% 的喘息空间。代价是我们现在只有 900 个 LBA 点可供操作系统写入和使用。
请注意,SSD 已预留一定比例的可用容量用于超额配置,无论如何。
使用 SSD 和非修剪操作系统
由于 XP 不“修剪”,我们可以通过增加为 SSD 预留的空间量来创造更多的空间来呼吸。一些 SSD 附带了执行此操作的工具(通过创建所谓的 HPA),因此这是实现此目的的一种选择。
本质上,您只需在 SSD 上保留一些未分区的空间即可实现相同的目的。所以我的建议看起来像这样:
只需运行它即可。没有虚拟机,没有帮助。这不是什么大问题——您永远不需要使用 TRIM 来驱动器工作。这样做对性能和寿命都有好处,但即使是杂乱的现代 SSD 也会比 Windows XP 预期的更快,而且即使开发工作负载繁忙,我也怀疑你是否会达到驱动器的 TBW 限制未来10年的任何时间。您需要移动大文件或运行数据库,因为写入量是一个大问题。
而且,您的主操作系统缺乏 TRIM 支持并不意味着您永远无法 TRIM。例如,您可以每月一次启动 Linux live-USB,安装 Windows 驱动器(如果默认情况下尚未执行此操作),在其上运行命令,等待其完成,然后重新启动
fstrim
。只是日常维护的一个小休息,有点像过去运行碎片整理(注意,不要运行碎片整理,它会让事情变得更糟而不是更好)。