Operating systems

The short version is: it does not work.

Having a SSD is feasible in the long run only if there is possibility of operating system informing the drive that an entire drive block (typically 16 KiB) can be erased. openSUSE wiki has following quote in it: "There are three terms often used to interchangeably describe this same basic functionality: Discard, UNMAP, and TRIM." This discard is possible only when there are no operating system sectors (typically 512 bytes) in the drive block.

Here is what I tried to do: I installed two Intel® Solid-State Drive 520 Series drives into my server and tried to see if RedHat-based CentOS 6.4 has enough backported bits & pieces to support RAID-1 /w TRIM.

The drives are fine and kernel TRIM-support is there:

hdparm -I /dev/sda | fgrep -i trim
           *    Data Set Management TRIM supported
           *    Deterministic read after TRIM

My initial attempt had GPT-partition table with a single RAID-partition on it. The command I used is:

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

I created EXT-4 on top of md0:

mkfs.ext4 /dev/md0

and mounted it:

mount /dev/md0 /mnt/tmp/ -o discard,noatime,nodiratime

The discard-support is in the kernel ok:

mount | fgrep md0
/dev/md0 on /mnt/tmp type ext4 (rw,noatime,nodiratime,discard)

The next thing I tried to do is confirm if TRIM does work either automatically or as a batch job. I followed instructions from this blog entry and tried to run hdparm --fibmap on a newly created file. It failed with a segfault. Apparently that is a known issue, so I ended up packaging the latest version myself. My own RPM-package is available at http://opensource.hqcodeshop.com/CentOS/6%20x86_64/hdparm-9.43-1.el6.x86_64.rpm.

With latest hdparm 9.43 I could verify that FIEMAP (file extent map)  ioctl() does not return correct results on a soft-RAID-1 device. The LBA-sector given by hdparm does not seem to contain the file's data.

My next attempt was to tear down the existing md0 and re-build it using entire drive as RAID-device.

mdadm --stop /dev/md0
mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sdb1
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
mkfs.ext4 /dev/md0
mount /dev/md0 /mnt/tmp/ -o discard,noatime,nodiratime

I ran the same test, but this time hdparm --fibmap informed it failed to determine the drive geometry correctly. A short peek into the source code revealed that current version of hdparm works only with partitions. It tries to load the RAID-partition start LBA even if it is not located on a partition. I made a quick fix for that, it turned out that /sys/block/md0/md/rd0/block has DEVTYPE=disk or DEVTYPE=partition to indicate the base drive type.

Nevertheless, it did not help. fibmap does not return the correct LBA-sector. I loaded a Bash-script to do the manual TRIMming of a SSD-RAID-1, but it only confirmed what I already knew. The LBA-mapping does not work enough to see if discard works or not.

Currently I don't have anything on my RAID-1, I'll have to see if it is possible to get the discard working somehow. A newer Linux might do the trick.