lkml.org 
[lkml]   [2013]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectSDD disk and unmap granularity value 0xFFFF
From
Hi,

I am facing an issue regarding unmap support with a couple of Intel SDD.

/dev/sde:

ATA device, with non-removable media
Model Number: INTEL SSDSA2BW300G3
Serial Number: BTPR245400ZL300EGN
Firmware Revision: 4PC10362
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II
Extensions, SATA Rev 2.5, SATA Rev 2.6

The problem I am facing is that vpd page 0xb0 returns 0xFFFF... for
unmap LBA count, descriptor count and granularity.

# sg_vpd -p 0xb0 /dev/sde
Block limits VPD page (SBC):
Optimal transfer length granularity: 0 blocks
Maximum transfer length: 0 blocks
Optimal transfer length: 0 blocks
Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
Maximum unmap LBA count: 4294967295
Maximum unmap block descriptor count: 4294967295
Optimal unmap granularity: 65535
Unmap granularity alignment valid: 0
Unmap granularity alignment: 0

# sg_vpd -p 0xb0 -H /dev/sde
Block limits VPD page (SBC):
00 00 b0 00 3c 00 00 00 00 00 00 00 00 00 00 00 00 ...<............
10 00 00 00 00 ff ff ff ff ff ff ff ff 00 00 ff ff ................
20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

The response looks valid, taking a look at Linux 3.12-rc3 (drivers/scsi/sd.c),

static void sd_read_block_limits(struct scsi_disk *sdkp)
{
.....
sdkp->unmap_granularity
=get_unaligned_be32(&buffer[28]);

.....
}

That value is never validated, the final outcome is that I do not have
TRIM support for those devices if I try to create a md raid0/1/10 with
any other SSD driver with granularity < 0xFFFF.

Have you ever seen a similar behaviour?

Regards,

Jesus


\
 
 \ /
  Last update: 2013-10-10 23:21    [W:0.029 / U:0.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site