[linux-lvm] Testing TRIM with LVM

Wed Apr 13 01:47:57 UTC 2011

On Apr 12, 2011 6:47pm, Mike Snitzer <snitzer at redhat.com> wrote:
> On Tue, Apr 12 2011 at 10:59am -0400,

> DarkNovaNick at gmail.com DarkNovaNick at gmail.com> wrote:

> > I recently purchased a Crucial C300 SSD and set it up as my primary

> > drive. I wanted to use LVM, and my reading indicates that LVM added

> > support to pass-through TRIM commands with kernel 2.6.37. I'm

> > running Ubuntu 10.10, but I installed the latest 11.04 kernel, so

> > I'm running kernel 2.6.38-8. I added "discard" to fstab so my

> > mountpoint looks like:

> >

> > /dev/mapper/vg0-vol0 on / type ext4

> > (rw,noatime,nodiratime,errors=remount-ro,discard,commit=0)

> If the discards aren't working then ext4 will print a warning and stop

> issuing them, see: http://git.kernel.org/linus/a30eec2a8650a77f7

> So if you don't see "discard not supported, disabling" in your dmesg (or

> /var/log/messages) then TRIM is likely working as expected.

> > I found directions on various sites like:

> >  
> http://duopetalflower.blogspot.com/2010/11/enterprise-kernel-6-has-ssd-trim.html

> > on how to confirm if TRIM is working. I ran (as root):

> >

> > dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct

> > hdparm --fibmap tempfile

> > (then took the first begin_LBA)

> > hdparm --read-sector 191710208 /dev/sda

> >

> > and it printed:

> >

> > /dev/sda:

> > reading sector 191710208: succeeded

> > 3254 3a32 3834 313a 2b36 3030 303a 2030

> > 4544 5542 2047 3728 3a29 5320 7661 6e69

> > 2067 6e69 6564 2078 6f66 2072 7270 646f

> > ............

> >

> > Then I ran:

> > rm tempfile

> > sync

> > hdparm --read-sector 191710208 /dev/sda

> >

> > and it still returned:

> > /dev/sda:

> > reading sector 191710208: succeeded

> > 3254 3a32 3834 313a 2b36 3030 303a 2030

> > 4544 5542 2047 3728 3a29 5320 7661 6e69

> > 2067 6e69 6564 2078 6f66 2072 7270 646f

> > .............

> >

> > If TRIM is working, the sector is supposed to contain all zeros.

> That is only if the SSD implements TRIM so that it zeroes the discarded

> blocks. You can check if the device at least knows enough to report

> discard_zeroes_data:

> cat /sys/block/sda/queue/discard_zeroes_data

> Also, even if the SSD does zero, it may take some time -- well after the

> discard has completed -- for the SSD to actually zero the blocks (this

> is true of some lesser quality SSDs).

> > Am I doing something wrong or do I need to do something more to get

> > LVM to pass down the TRIM command?

> LVM (device mapper specifically) passes discards perfectly well. But

> the snapshot and dm-crypt targets don't have discard support. All other

> targets do have discard support. What is your output for: dmsetup table

> Mike

I get 0 back when I do "cat /sys/block/sda/queue/discard_zeroes_data" so  
does this mean that my drive doesn't zero out the TRIMed blocks? I don't  
really care if it does or does not, I just want to make sure the drive is  
getting the TRIM commands as the benchmarks I've seen show performance  
degradation if they aren't used.

Regarding snapshot targets, the only instance of "discard not supported"  
came as I did a snapshot today:

Apr 12 15:27:58 darknovanick kernel: [65147.211211] EXT4-fs warning (device  
dm-0): release_blocks_on_commit:2672: discard not supported, disabling
Apr 12 15:28:16 darknovanick kernel: [65166.103061] EXT4-fs (dm-1): 72  
orphan inodes deleted
Apr 12 15:28:16 darknovanick kernel: [65166.103062] EXT4-fs (dm-1):  
recovery complete
Apr 12 15:28:17 darknovanick kernel: [65166.232257] EXT4-fs (dm-1): mounted  
filesystem with ordered data mode. Opts: (null)

This snapshot was of a LV on the SSD, but the snapshot itself was being  
stored on a mechanical hard drive. Does this message mean that discard was  
just disabled for the snapshot itself (which was deleted a half hour  
later), or is it now disabled for the entire volume now that I've done a  
snapshot, even though its been removed?

My dmsetup table output:

vg0-vol0: 0 249438208 linear 8:2 512

Thanks,

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20110413/802fb886/attachment.htm>