背景丢弃在Linux + SSD的交换分区上

问题

我想在Linux上的SSD磁盘内的交换分区上启用后台 TRIM操作。 根据几篇文章，例如这个 ，内核检测到这个configuration并且自动执行丢弃操作，但是在我的testing中似乎没有工作，尽pipe使用了“discard”挂载选项来强制这个行为。

脚本

• Debian Wheezy运行Linux 3.2.0
• SSD磁盘：1 x 120GB OCZ Vertex 3 MI
• 2GB交换“普通”分区，无其他层（LVM，RAID等）

背景

• 我如何解释MCE消息？
• 如何判断磁盘在ESXi上是否失败/这些错误是什么意思？
• 如何在puppet中为服务使用自定义状态命令？
• 文件系统访问速度慢
• 在RAIDarrays降级时启动Debian

以下是检查背景TRIM是否在交换分区上工作的步骤：

1. TRIM支持 ：检查SSD磁盘是否支持TRIM命令，内核将设备标记为非旋转：

   # hdparm -I /dev/sda | grep TRIM * Data Set Management TRIM supported (limit 1 block) * Deterministic read data after TRIM # cat /sys/block/sda/queue/rotational 0 

2. 交换填满 ：挂载分区，清理所有虚拟机高速caching，并configurationLinux以积极地将vm.swappiness设置为100.然后，运行一个脚本来分配所有可用的内存，并强制内核开始交换：

    # swapon [--discard] /dev/sda2 # echo 3 > /proc/sys/vm/drop_caches # echo 100 > /proc/sys/vm/swappiness # ./fill-up-memory.up 

   该脚本在32GB物理内存+ 2GB交换分区上运行一个服务器，并在内存中创build一个〜33.8GB的对象，这足以填满所有内存并开始交换。 这是实现此行为的脚本示例：

    #!/usr/bin/python mem = 33.8 testing = 'A' * int(1024 * 1024 * 1024 * mem) raw_input() 

3. 检查交换内容 ：“swapon -s”显示使用了100％的交换内存。 使用“hdparm –read-sector”检查交换分区扇区的原始内容，并将所有字节设置为“4141”，即“A”字符对应的hex符号，一切正常。 这是一个示例脚本来逐个读取交换分区的内容：

    #!/bin/bash for sector in `seq 194560 4100095` ; do hdparm --read-sector $sector /dev/sda done 

注：您可以使用parted，cfdi​​sk等获取交换分区的开始/结束扇区。

当我停止脚本时，它将释放所有内存，包括交换分配，“swapon -s”在系统中不返回交换使用。 在这一点上， 预计Linux会在后台开始丢弃交换分区的内容，但不起作用 ，这些扇区的内容仍然是“4141”，甚至几个小时之后。

我做了几个testing，似乎只有在使用swapon()系统调用启用分区时，Linux才会执行完全丢弃操作，但从swapon()后台，尽pipe在/ etc / fstab上启用了“discard”挂载选项。

进一步的研究：blkdev_issue_discard（）是负责发送TRIM命令到底层SSD设备的内核函数，在mm/swapfile.c上有这个函数的两个唯一引用：

• discard_swap()在swapon（）过程中被调用，如果启用了“discard”挂载选项，它会丢弃所有的内容，这可以按预期工作。
• discard_swap_cluster()应该丢弃集群交换的内容，但似乎从不执行TRIM命令。

问题： Linux在swap + SSD设备上的预期行为是什么？ 它应该丢弃所有空闲的扇区/页面，或者只在启动过程中启用分区时才发出初始完全丢弃？ 谢谢。

 # nano /etc/fstab ________________________________________________________________ ... /dev/sda2 none swap ..., --discard=pages,... ... ...