Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote:
> 
> Kashyap,

Hi Martin,

> > Sorry, I didn't give you complete information — with the previous
> > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB
> > "A Cable".  
> >
> > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop
> > (Lenovo T470s), it _does_ show "UAS".   Refer the arrow below:
> 
> Do you get different sg_readcap -l output when accessing it in UAS mode?
> I.e. is lbpme=1?

Afraid, no :-(  I was excited for a brief moment, but it's the same as
earlier.  The result with the SSD via 'Thunderbolt':

    $> sudo sg_readcap -l /dev/sdc
    Read Capacity results:
       Protection: prot_en=0, p_type=0, p_i_exponent=0
       Logical block provisioning: lbpme=0, lbprz=0
       Last logical block address=976773167 (0x3a38602f), Number of logical blocks=976773168
       Logical block length=512 bytes
       Logical blocks per physical block exponent=0
       Lowest aligned logical block address=0
    Hence:
       Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB


/me naively wonders if it has anything to do with accessing it via
Linux.

-- 
/kashyap



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux