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

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

 



On Thu, Mar 15, 2018 at 12:19:11PM +0100, Douglas Gilbert wrote:
> On 2018-03-15 10:47 AM, Kashyap Chamarthy wrote:
> > 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.
> 
> You can also run 'sg_readcap -l' on a Windows machine to test your theory.
> Do 'sg_scan.exe' first to see where (and if) the 'physical disk' is, then
> you would do something like:
>     sg_readcap -l pd2
> 
> There is no IOS port of sg3_utils.
> 
> I am not aware of any SCSI command *** (and haven't seen any ATA or NVMe
> commands) that tell a storage device something like: "BTW I'm a Linux
> machine running Ubuntu 17.10 on xxxx hardware".
> 
> It is possible that a storage device might recognize an OS by the pattern
> of commands it sends, especially in the device discovery mode.
> 
> So basically your suggestion is a long shot. There might be a "secret"
> setting in a vendor specific command that another OS is aware of.
> For example, according to the 'net this command:
>    sg_raw /dev/sr0 EA 00 00 00 00 00 01
> allows owners of Apple USB Superdrives to use them on other OSes.

I see, thanks for the explanation and the specific useful commands.
I'll try to get hold of a friend's Windows computer, as I don't have one
with me.  But your "long shot" comment adjusted my expectations to not
hold my breath.

> *** there are transport_ids used by PERSISTENT RESERVATION commands to
>     differentiate one machine from another. But they convey about as
>     much information as a random number does. Also that applies to a
>     multi-initiator, single target model which isn't the case when we
>     are talking about USB/Thunderbolt attachment.
> 

-- 
/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