PCI-e-SSD discard support on RHEL 6 ?

Some more information wouldn't hurt:

- what model (Dell) server?

- which raid controller is in the server?

- what model SSD? If non-Dell, which brand and model?

If it's an SSD that didn't come with the server from the factory, but you bought it elsewhere, you may want to check with the manufacturer of that SSD (and it then still may depend on the storage controller that you're using).

Hello Luc

Yes, RHEL 6 and the EXT4 file system support trim. I found a great write up that describes how to verify trim is functioning. Since trim notifies SSD's on which blocks can be discarded the testing method involves writing something to a block, deleting the block, and then checking that block to see if there is still data present on the drive. Here is the article I found:

http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2

Thanks

Knowing the installed RAID card would only be relevant in determining if the RAID card support flash features like TRIM, etc, for any SATA or SAS SSD's connected to the ports of that card itself. PCIe flash memory cards are different beasts.

Iblast2, the manufacturers specification sheet for your PCIe flash card should indicate what flash features are supported. If not, the manufacturer should be able to clarify the feature set of your card.

Hi all,

Thanks for the replies.

1. Some details about the hardware:

   Dell PowerEdge R720 - 192GB memory - PERC H710p Integrated RAID Controller.

   4 x Dell Express Flash 300GB PCIe-SSD (micron)

   Those PCI-e SSD are not connected to any RAID controller but visual under RHEL6 as /dev/ssd{a,b,c,d}

2. I did follow the advice from techgage.com/.../2

    I had some issues with hdparm --fibmap.  The standard hdparm installed with RHEL 6.3 core dumps.  

   I replaced it with hdparm-9.36-2.fc15.

   hdparm --read-sector  fails with 'The running kernel lacks CONFIG_IDE_TASK_IOCTL support for this device'.

3. I had come up with the following test based on previous article:

 mkfs.ext4 /dev/rssda

 mount -vv -t ext4 -o discard,noatime /dev/rssda /mnt

 echo 'testing' >/mnt/tempfile

 hdparm --fibmap /mnt/tempfile

     filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.

     byte_offset  begin_LBA    end_LBA    sectors

                          0     270344     270351          8

 hexdump /dev/rssda -n 512 -s 270344b

     8401000 6574 7473 6e69 0a67 0000 0000 0000 0000

    8401010 0000 0000 0000 0000 0000 0000 0000 0000

    *

    8401200

Notice that 6574 7473 6e69 0a67 is the hex representation of the string 'testing'

Next I removed /mnt/tempfile and generated another hexdump.

So far the string 'testing' is still present.

Although I'm not sure if trimming also zeroes out the disk sectors involded.

Is it correct to use hexdump instead of hdparm --read-sector ?

What about parameters in /sys/block/rssda/queue ?

for example: cat /sys/block/rssda/queue/discard_zeroes_data retuns 0

Hexdump should work fine. It does not matter what method you use. The goal of the test is to place data into a block address on a the SSD and delete, sync, and then use some block level checking to make sure the data is gone.

I may have missed it or you may have left it out, but it appears you skipped the syncing portion. I would suggest testing once more with running the sync command.

If it still fails then provide the model number of the drive and I will make sure it supports TRIM.

Hi,

I have tested it with the sync command and also waited 3 days.

Model Number:       DELL_P320h-MTFDGAL350SAH

Firmware Revision:  B1442808

Kind regards,

Luc

I'm showing that the drive does support garbage collection(trim, discard).

Try running the mount command to verify discard is enabled.

for example: cat /sys/block/rssda/queue/discard_zeroes_data retuns 0

I'm pretty sure trim/discard is working correctly. The reason we did not get the expected outcome of all 0's is because your settings are not configured to zero out trim'd blocks. That is what that output means.

Another test you could run to verify is to either enable zeroing out blocks and run the same test again, or you could try overwriting the existing block with something like a touch command(touch {000..999}). If you run the command from the same location it will likely overwrite the same block. If you are able to overwrite a previously deleted block then discard is working.

If you want to enable zeroing out blocks then you can run:

# echo 1 > /sys/block/rssda/queue/discard_zeroes_data

I would not recommend leaving the option set to zero out blocks. It causes unnecessary writes to the drive.

Thanks

Hi all,

I've done the test as suggested with the touch command.

After a few syncs and umount/mount command the same blocks were overwritten.

Same test was done on a ext4 fs mounted on a md0 device - RAID 10 on /dev/rssd{a,b,c,d}

Conclusion is that discard is indeed working on a single device (/dev/rssda)  and also on a md0 device.

Thanks for tips

Luc

Hi again,

Last week I got an email from the Dell Support telling me that this drive

does not do any trimming like most SSD drives do but a sort of 'wear leveling'.  

The drive contain a great number of reserve cells, more than 'consumer grade' SSD drives

and therefore does not need 'trimming'.

This news is abit disturbing:

- Why does ext4 not complain when mounting with the 'discard' flag ?  It should if the

  drive does not support 'trimming'. (referring to the RedHat manual)

- Why does manufacturer Micron not give more detailed information about their product.

  There is a link on there website to a manual and management sofware but only accessable

  after approval.  

All comments are welcome

Kind regards,

Luc