On 17 August 2017 at 10:11, Martin K. Petersen
wrote:
>
> Tom,
>
> I have to confess I'm wary of interpreting values reported by a device
> that messes up setting the single bit flag that enables the feature.
>
FWIW, this implementation in particular works pretty well as far as I
can tell. The va
as the sd driver does either.
I think sd_read_write_protect_flag should be made general for reading
both the WP and the DPOFUA bits, while sd_read_cache_type should be
freed from the job.
Any comments and insights are welcomed.
Regards,
Tom Yan
--
To unsubscribe from this list: send the line &qu
On 23 August 2016 at 10:45, Shaun Tancheff wrote:
> On Tue, Aug 23, 2016 at 5:17 AM, Tom Yan wrote:
>> Wait a minute. I think you missed or misunderstood something when you
>> listen to someone's opinion in that we should switch to sglist buffer.
>
> No, I think I can t
with invalid CDB field if we catch that.
Though IMHO this is really NOT a reason that is strong enough to
prevent this patch from entering the repo first.
On 23 August 2016 at 09:36, Tom Yan wrote:
> On 23 August 2016 at 09:18, Shaun Tancheff wrote:
>> On Tue, Aug 23, 2016 at 3:37 AM,
On 23 August 2016 at 09:18, Shaun Tancheff wrote:
> On Tue, Aug 23, 2016 at 3:37 AM, Tom Yan wrote:
>> On 23 August 2016 at 07:30, Shaun Tancheff wrote:
>
>> If we really want/need to avoid hitting some real buffer limit (e.g.
>> maximum length of scatter/gather list?)
On 23 August 2016 at 08:37, Tom Yan wrote:
> On 23 August 2016 at 07:30, Shaun Tancheff wrote:
>>
>> But the "humanized" limit is the one you just added and proceeded to
>> change ata_set_lba_range_entries(). You changed from a buffer size
>> to use "n
On 23 August 2016 at 07:30, Shaun Tancheff wrote:
>
> But the "humanized" limit is the one you just added and proceeded to
> change ata_set_lba_range_entries(). You changed from a buffer size
> to use "num" instead and now you want to remove the protection
> entirely?
I am not sure about what yo
On 22 August 2016 at 20:32, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 3:07 PM, Tom Yan wrote:
>> I don't see how that's possible. count / n_block will always be
>> smaller than 65535 * ATA_MAX_TRIM_RNUM(64) = 4194240. Not to mention
>> that isn't even
t's the case, that's what exactly commit 5c79097a28c2
("libata-scsi: reject WRITE SAME (16) with n_block that exceeds
limit") is for.
On 23 August 2016 at 03:58, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 1:55 PM, wrote:
>> From: Tom Yan
>>
>>
On 14 August 2016 at 11:10, Pavel Machek wrote:
>
> It is the case in v4.6. We had change hda->sda for SATA drives long
> time ago, it was stable since that.
Not for me. It has been like forever (even if it wasn't the fact) that
the disk order is not consistent among boots. Only that would
logica
On 14 August 2016 at 17:00, Tom Yan wrote:
>
> That won't really work. min_t() would, though the line is gonna be a
> bit long; not sure if I can/should simply cast the type (unsigned int)
> to BLK_DEF_MAX_SECTORS. And which braces are you referring to?
>
Oh you mean the else-
On 13 August 2016 at 04:56, Martin K. Petersen
wrote:
>>>>>> "Tom" == Tom Yan writes:
>
> Tom,
>
>>> put_unaligned_be64(65535 * ATA_MAX_TRIM_RNUM / (sector_size / 512),
>>> &rbuf[36]);
>
> How many 8-byte ranges fit in a 4096-by
On 13 August 2016 at 05:37, Martin K. Petersen
wrote:
>
> It would be pretty unusual for a device that is smart enough to report a
> transfer length limit to be constrained to 1 MB and change.
>
Well, it is done pretty much for libata's SATL. Also since
opt_xfer_blocks is checked against dev_max,
On 13 August 2016 at 04:26, Martin K. Petersen
wrote:
>>>>>> "Tom" == Tom Yan writes:
>
> Tom,
>
> Tom> I don't really follow. What would this BLK_MAX_BIO_SECTORS be? It
> Tom> doesn't appear to me that a static value is going
On 12 August 2016 at 21:42, Sergei Shtylyov
wrote:
> On 08/12/2016 02:56 PM, tom.t...@gmail.com wrote:
>
>> From: Tom Yan
>>
>> Currently we use dev->max_sectors to set max_hw_sectors, which
>> is actually supposed to be a host controller limit (that get set
On 12 August 2016 at 19:56, wrote:
>
> Also note that ATA_HORKAGE_MAX_SEC_LBA48 is not supposed to work
> automatically anyway, even when max_hw_sectors is as high as 65535,
> since the effective max_sectors will be set by the SCSI disk driver.
>
I missed the fact that ATA_HORKAGE_MAX_SEC_LBA48 i
On 12 August 2016 at 13:18, Tom Yan wrote:
> On 12 August 2016 at 10:01, Martin K. Petersen
> wrote:
>>
>> Again, the point of max_hw_sectors and max_dev_sectors is to enforce the
>> hard limits of controller and device respectively. Nothing else.
>>
>
&
On 12 August 2016 at 10:01, Martin K. Petersen
wrote:
>
> Again, the point of max_hw_sectors and max_dev_sectors is to enforce the
> hard limits of controller and device respectively. Nothing else.
>
Sounds like libata-scsi is doing something wrong then. It should not
set max_hw_sectors to dev->m
On 12 August 2016 at 09:34, Martin K. Petersen
wrote:
>> "Tom," == tom ty89 writes:
>
> Tom,
>
> + put_unaligned_be64(65535 * ATA_MAX_TRIM_RNUM /
> + (sector_size / 512), &rbuf[36]);
>
> MAXIMUM WRITE SAME LENGTH is in units of the device's logic
On 12 August 2016 at 11:10, Martin K. Petersen
wrote:
>
> However, the CDB transfer length limit is really not the main issue
> here, it's bi_size that we need to enforce.
>
> After contemplating a bit I think it would be cleanest to add
> BLK_MAX_BIO_SECTORS and clamp on that in blk_queue_max_foo
I should have probably used the bit shift
way instead.
On 11 August 2016 at 17:04, Shaun Tancheff wrote:
> On Thu, Aug 11, 2016 at 3:26 AM, wrote:
>> From: Tom Yan
>>
>> Currently we advertise Maximum Write Same Length based on the
>> maximum number of sectors that
On 11 August 2016 at 11:37, Martin K. Petersen
wrote:
>>>>>> "Tom" == Tom Yan writes:
>
> I don't agree with conflating the optimal transfer size and the maximum
> supported ditto. Submitting the largest possible I/O to a device does
> not guaran
ce of
having io_opt set.
On 10 August 2016 at 12:10, Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 09, 2016 at 10:45:47PM +0800, tom.t...@gmail.com wrote:
>> From: Tom Yan
>>
>> Currently block layer limit max_hw_sectors is set to
>> ATA_MAX_SECTORS_LBA48 (65535), for dev
On 10 August 2016 at 15:41, David Milburn wrote:
> Hi,
>
> The 168 makes AHCI_CMD_TBL_SZ equal to 2816
>
> AHCI_CMD_TBL_SZ = AHCI_CMD_TBL_HDR_SZ + (AHCI_MAX_SG * 16)
> AHCI_CMD_TBL_SZ = 128 + (168 * 16)
>
> I think if you add in AHCI_CMD_SLOT_SZ (1024) and AHCI_RX_FIS_SZ (256)
> the DMA is 4K alig
On 10 August 2016 at 11:26, Tejun Heo wrote:
> Hmmm.. why not? The hardware limit is 64k and the driver is using a
Is that referring to the maximum number of entries allowed in the
PRDT, Physical Region Descriptor Table (which is, more precisely,
65535)?
> lower limit of 168 most likely because
Withdrawn. blk_queue_max_hw_sectors() is not called in hosts.c but in
scsi_lib.c. However, it does not check the dev->max_sectors set in
libata-core.c. So everything of this patch is wrong. Will rewrite and
resend the second patch.
On 9 August 2016 at 18:31, wrote:
> From: Tom Yan
So the (not so) recent bump of BLK_DEF_MAX_SECTORS from 1024 to 2560
(commit d2be537c3ba3) seemed to have caused trouble to some of the ATA
devices, which were then worked around with ATA_HORKAGE_MAX_SEC_1024.
However, I am suspecting that the bump of BLK_DEF_MAX_SECTORS is not
the "real" cause of
Yes, because it touches an actual ATA drive setting, while D_SENSE is
merely a "software setting" stored in dev->flags to make the kernel
response differently when build sense data.
On 26 July 2016 at 02:30, Tejun Heo wrote:
> On Fri, Jul 22, 2016 at 05:50:18AM +0800, Tom Yan w
Strange. I merely changed the two "char" to "u8". I wonder how the tab
became spaces. Anyway, sorry about that, resending soon.
On 22 July 2016 at 17:59, Sergei Shtylyov
wrote:
> Hello.
>
>
> On 7/22/2016 2:29 AM, tom.t...@gmail.com wrote:
>
>> F
This is actually a bit clumsy. Sending a rewritten version.
On 22 July 2016 at 02:41, wrote:
> From: Tom Yan
>
> Commit 7780081c1f04 ("libata-scsi: Set information sense field for
> invalid parameter") changed how ata_mselect_*() make sure read-only
> bits
As I've mentioned in the comment/message, there is no ATA command
needed to be sent to the device, since it only toggles a bit in
dev->flags. See that there is no ata_taskfile constructed in
ata_mselect_control().
On 22 July 2016 at 05:26, Tejun Heo wrote:
> On Fri, Jul 22, 2016 at 02:41:54AM +08
2:41:52AM +0800, tom.t...@gmail.com wrote:
>> From: Tom Yan
>>
>> ata_mselect_*() would initialize a char array for storing a copy of
>> the current mode page. However, if char was actually signed char,
>> overflow could occur.
>
> Do you mean sign extension?
>
This patch should cause no behavioral change. Even the (removal of)
the redundant bit mask should be a nop. So it seems like a bit of an
overkill to split them.
On 22 July 2016 at 02:45, Sergei Shtylyov
wrote:
> Hello.
>
> On 07/21/2016 09:41 PM, tom.t...@gmail.com wrote:
>
>
Wrongly marked this as a "v4". It's actually a "v1".
On 20 July 2016 at 05:11, wrote:
> From: Tom Yan
>
> 1. Removed a repeated bit masking in ata_mselect_control()
> 2. Moved `wce`/`d_sense` assignment below the page validity checks
> 3. Added/Removed
Oops I put the wrong action under the opposite condition. Sending a v2.
On 20 July 2016 at 06:50, wrote:
> From: Tom Yan
>
> Commit 7780081c1f04 ("libata-scsi: Set information sense field for
> invalid parameter") changed how ata_mselect_*() make sure read-only
> bits
the bit shifting/masking results
because it appears that the rest of the code in libata-scsi.c does
that as well. So I am not going to partially clean up that to avoid
making it look inconsistent.
On 20 July 2016 at 04:39, wrote:
> From: Tom Yan
>
> `changeable` is the "version"
So I recently been doing some experiment on different storage hosts
(AHCI and UAS) to see how certain block layer limits in the kernel and
so matters on them. I notice some behavior in SATA/AHCI which bothers
me a bit.
I have been testing with `sg_raw` by issuing READ (10/16) commands.
But before
On 14 July 2016 at 01:03, Tejun Heo wrote:
>
> It's used to device max_sectors.
>
Not really. "max_sectors" of ATA drives have been set to
BLK_DEF_MAX_SECTORS, for at least quite some time.
>
> This is way too gratuitous. There's no rationale for it while it has
> actual real-world risks. max_
By looking at what the scsi disk
driver do, it appears that it's a sensible thing to set the limit to a
value that matches with the other limit "max_sectors", though.
On 14 July 2016 at 01:04, Tejun Heo wrote:
> On Wed, Jul 13, 2016 at 12:47:08PM +0800, tom.t...@gmail.com wrote:
n Wed, Jul 13, 2016 at 12:20:40AM +0800, Tom Yan wrote:
>> First of all "changeable" is the "version" of mode page requested by
>> the user, while ata_id_*_enabled(id) are the value of setting reported
>> by the device. I think it's ugly and confusing to
Btw, why is the MODE SELECT function called ata_mselect_control()
while the MODE SENSE function is called ata_msense_ctl_mode()?
Shouldn't we make their names consistent?
On 13 July 2016 at 01:35, wrote:
> From: Tom Yan
>
> The bit should always be set to 1 when the requested ver
ways be "1" / "y", since
we've made (only) it changeable in ata_mselect_caching(); and when the
user request the current / default page, the values reflect the
settings from the drive.
On 12 July 2016 at 22:48, Tejun Heo wrote:
> On Tue, Jul 12, 2016 at 09:37:03PM +080
Since version 1.10, sdparm would return the mode page "Write
parameters" if the MODE SENSE data from the device has a 05h mode
page. However, the page number was also used for mode page called
"Flexible geometry":
[tom@localhost ~]$ sudo sdparm /dev/sdb
/dev/sdb: SanDisk Ultra II 240GB0
nyway.
Well, it is alright to have an "sg_sat_sanitize" (which makes use of
ATA PASS-THROUGH like other sg_sat_*) though. I am just not sure if
sg3_utils should go on having more sg_sat_*...
On 9 July 2016 at 08:49, James Bottomley
wrote:
> On Fri, 2016-07-08 at 19:38 +, Tom Y
On 8 July 2016 at 17:29, James Bottomley
wrote:
>
> OK, since you ignore the argument about maintenance: safety for us
> means that it doesn't bitrot as an almost never used addition. The
> reason our SATL should only support the commands Linux uses is
> precisely because if it's used often we ge
ank, saying that implementing it in the "SAT-way"
would make it untrustable doesn't make any sense to me, especially
when the way the feature set works is considered.
On 8 July 2016 at 00:47, James Bottomley
wrote:
> On Fri, 2016-07-08 at 00:32 +0800, tom.t...@gmail.com wrote:
>
e
an identification descriptor containing a logical unit name as defined
in 10.5.4.2.3.
(sat4r05f.pdf)
On 7 July 2016 at 20:44, Hannes Reinecke wrote:
> On 07/07/2016 02:40 PM, Tom Yan wrote:
>> Well, udev uses its own `ata_id` (which issues IDENTIFY DEVICE through
>> ATA PASS
Sorry I am a bit new in this. Does that mean I should also use {} for
the if clause even it has only one line of statement, because I
(needed to) use that for the else clause? So it should be like:
if ... {
...
} else {
...
...
}
On 7 July 2016 at 18:55, Sergei Shtylyov
wrote:
>
>
deemed as some sort of
reference), so I gave it a go.
Not that SAT requires the DI VPD return only one desingator / LU name though.
On 7 July 2016 at 18:56, Hannes Reinecke wrote:
> On 07/07/2016 12:12 AM, tom.t...@gmail.com wrote:
>> From: Tom Yan
>>
>> SAT (as of sat4
I am so sorry. Now I hate acronym. v5 coming. :-)
On 7 July 2016 at 01:02, Sergei Shtylyov
wrote:
> On 07/06/2016 07:44 PM, tom.t...@gmail.com wrote:
>
>> From: Tom Yan
>>
>> Currently if a WRITE SAME (16) command is issued to the SATL with
>> "number of block
I decided not to define a macro (e.g. ATA_MAX_TRIM_RSIZE) for all the
0x / 65535 in the various functions in libata-scsi.c / ata.h. Let
me know if you think I should.
On 7 July 2016 at 00:55, wrote:
> From: Tom Yan
>
> Currently libata statically allows only 1-block (512-byte
Oops I missed the block limit VPD this time. Will send a v4.
On 7 July 2016 at 00:44, wrote:
> From: Tom Yan
>
> Currently libata statically allows only 1-block (512-byte) payload
> for each TRIM command. Each payload can carry 64 TRIM ranges since
> each range requires 8 b
Um it's not mainly about in caps or not, but more about wrongly spelled as cbd.
On 5 July 2016 at 22:39, Tejun Heo wrote:
> Hello,
>
> On Wed, Jul 06, 2016 at 03:13:31AM +0800, Tom Yan wrote:
>> I just thought that such a minor change in a comment can fit in the
>> same
I just thought that such a minor change in a comment can fit in the
same patch where the issue was first noticed. Anyway, will split them
if I am going to send a v3 set.
On 5 July 2016 at 19:08, Sergei Shtylyov
wrote:
> On 7/5/2016 9:45 AM, tom.t...@gmail.com wrote:
>
>> From: Tom Y
though the comment of it seems to tell otherwise). That's why I
(could) changed the function itself and the param ("512")
ata_scsi_write_same_xlat() passes to it.
On 5 July 2016 at 19:04, Sergei Shtylyov
wrote:
> Hello.
>
> On 7/5/2016 9:45 AM, tom.t...@gmail.com wrote
by sd, they can use BLOCK LIMITS VPD to
> tell it to do so.
>
>
>> -Original Message-
>> From: Tom Yan [mailto:tom.t...@gmail.com]
>> Sent: Saturday, June 4, 2016 1:41 AM
>> To: Long Li
>> Cc: James E.J. Bottomley ; Martin K. Petersen
>> ; linux-scsi@
The main point there is not to check q->limits.max_sectors against
BLK_DEF_MAX_SECTORS, but sdkp->opt_xfer_blocks against
SD_DEF_XFER_BLOCKS et al.? `rw_max = BLK_DEF_MAX_SECTORS;` there is
merely the fallback when sdkp->opt_xfer_blocks does not pass the
conditions. With your patch `rw_max` can be
or causes a rescan to be
> initiated, which results in endless error messages.
>
> On Fri, 2016-06-03 at 03:15 +, Tom Yan wrote:
>> Why not get qemu have it fixed instead?
>>
>> On Tuesday, 31 May 2016, Johannes Thumshirn
>> wrote:
>> On Tue, May
Why not get qemu have it fixed instead?
On 31 May 2016 at 21:43, Johannes Thumshirn wrote:
> On Tue, May 31, 2016 at 09:42:29AM -0400, Ewan D. Milne wrote:
>> Linux fails to boot as a guest with a QEMU CD-ROM:
>>
>> [4.439488] ata2.00: ATAPI: QEMU CD-ROM, 0.8.2, max UDMA/100
>> [4.443649]
There seems to be some sort of race condition between
blkdev_issue_zeroout() and the scsi disk driver (disabling write same
after an illegal request). On my UAS drive, sometimes `blkdiscard -z
/dev/sdX` will return right away, even though if I then check
`write_same_max_bytes` it has turned 0. Some
t;>>
>>>>> This is incorrect, without the scsi_change_queue_depth() call the
>>>>> slave's queue_depth defaults to 1, introducing a performance
>>>>> regression.
>>>>>
>>>>> This commit restores the call, fixing th
In this commit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/storage/uas.c?id=198de51dbc3454d95b015ca0a055b673f85f01bb
There is the following comment:
> 1 tag is reserved for untagged commands
So my question is, what exactly are "untagged commands"?
If we ne
On 24 May 2016 at 01:36, James Bottomley
wrote:
>
> Are you sure about this? For spinning rust, experiments imply that the
> optimal queue depth per device is somewhere between 2 and 4. Obviously
> that's not true for SSDs, so it depends on your use case.
Are we supposed to care about the stora
patch that simply has `.can_queue =
MAX_CMNDS` in the host template removed?
On 24 May 2016 at 01:27, James Bottomley
wrote:
> On Tue, 2016-05-24 at 01:23 +0800, Tom Yan wrote:
>> Nothing wrong. It's just .can_queue = MAX_CMNDS in the host template
>> is no longer neceesary, since
eue
more then MAX_CMNDS...")
On 24 May 2016 at 01:00, Greg KH wrote:
> On Tue, May 24, 2016 at 12:02:43AM +0800, tom.t...@gmail.com wrote:
>> From: Tom Yan
>>
>> Commit 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level") made
>> qde
Btw, I suppose `.can_queue = MAX_CMNDS` in the host template is
unnecessary (unless we are going to revert `shost->can_queue =
devinfo->qdepth - 2`)?
On 22 May 2016 at 18:39, Tom Yan wrote:
> With commit 198de51dbc3454d95b015ca0a055b673f85f01bb, uas no longer
> set `queue
With commit 198de51dbc3454d95b015ca0a055b673f85f01bb, uas no longer
set `queue_depth` with scsi_change_queue_depth(), so now `queue_depth`
of UAS drives are 1. Even though `can_queue` is set to
`devinfo->qdepth - 2`, but apparently that does not help, since I can
see performance impact.
Suppose li
On 12 May 2016 at 12:04, Fam Zheng wrote:
>
> Following is:
>
> else
> rw_max = BLK_DEF_MAX_SECTORS;
>
> Which seems in sector unit, and is already making above change suspicious, and
Yes BLK_DEF_MAX_SECTORS is in sector unit. It has been bumped from
1024 to 2560 not long
nsport
ATA command IDENTIFY DEVICE response summary:
model: INTEL SSDSC2BW240A4
serial number: CVDA339603M02403GN
firmware revision: DC32
On 4 May 2016 at 02:19, Douglas Gilbert wrote:
> On 2016-05-02 04:13 PM, tom.t...@gmail.com wrote:
>>
>> From: Tom Yan
>>
>&
ng the bit statically to 1?
On 3 May 2016 at 04:13, wrote:
> From: Tom Yan
>
> https://bugzilla.kernel.org/show_bug.cgi?id=105931
>
> This might look trivial at first sight. However, it can be
> important to have the bit set accordingly when the device/SATL is
> SCSI-passthro
the BOT driver).
If it's lower than that (e.g. 2 times - 7 times), it seems some queued
UNMAP commands are rejected by my device, but the xhci_hcd error will
not be triggered.
On 12 March 2016 at 09:41, Tom Yan wrote:
> So I have a USB-SATA bridge that supports translating SCSI UNMAP to
>
But yeah if it has unmap granularity reported to be, for example, 16,
then it will not be correctly set with min_not_zero().
Wait, shouldn't it be:
max(sdkp->logical_block_size,
sdkp->unmap_granularity * logical_block_size);
then?
On 12 March 2016 at 13:37, Tom Yan wrote:
n 12 March 2016 at 05:41, Martin K. Petersen
wrote:
>>>>>> "Tom" == Tom Yan writes:
>
> Tom,
>
> Tom> Would min_not_zero() be more proper than max()?
>
> That would effectively set discard_granularity to physical_block_size
> regardless of whether
Would min_not_zero() be more proper than max()?
On 11 March 2016 at 20:37, Martin K. Petersen
wrote:
>>>>>> "Tom" == Tom Yan writes:
>
> Tom,
>
> Tom> In that case, if the granularity only act as some sort of
> Tom> "reference" but has
On 11 March 2016 at 10:16, Martin K. Petersen
wrote:
>
> Discard is advisory, the command will not get rejected.
>
In that case, if the granularity only act as some sort of "reference"
but has no real "binding" to the actual behaviour, why would the
kernel even "make up" the granularity itself ac
On 10 March 2016 at 12:36, Tom Yan wrote:
>
> Both `blkdiscard` with a patched kernel and `sg_unmap` appeared to
> have gone well (checked with `hexdump`).
>
Actually, `blkdiscard` didn't quite actually go well. It seems last
time it just ended quickly with only error on kern
ter being discarded"; instead, it's just "we did not discard
the 512-byte block as per requested because it's not allowed".
On 10 March 2016 at 16:16, wrote:
> From: Tom Yan
>
> According to its own comment, the discard granularity should
> fixed to the logica
March 2016 at 10:32, Martin K. Petersen
wrote:
>>>>>> "Tom" == Tom Yan writes:
>
> Tom> Btw, why SD_MAX_WS16_BLOCKS (which is used for both SD_LBP_WS16 and
> Tom> SD_LBP_UNMAP) is set to 0x7f (23-bit) instead of 0x
> Tom> (32-bit, 4-byte)?
The outputs were made with an SSD that supports TRIM plugged in:
[tom@localhost ~]$ sudo smartctl --identify=wb /dev/sdc | grep -i trim
69 14 1 Deterministic data after trim supported
69 5 1 Trimmed LBA range(s) returning zeroed data supported
169 0
present (DP): 0
Minimum percentage: 0
Provisioning type: 0
Threshold percentage: 0
On 9 March 2016 at 11:26, wrote:
> From: Tom Yan
>
> Some devices have details of their support on unmapping on the
> Block Limits and/or Logical Block Provisioning VPDs while they
> do not se
9 March 2016 at 11:30, Tom Yan wrote:
> Example device, JMicron JMS567 UAS SATA bridge:
>
> [tom@localhost ~]$ sudo sg_readcap -16 /dev/sdc
> Read Capacity results:
>Protection: prot_en=0, p_type=0, p_i_exponent=0
>Logical block provisioning: lbpme=0, lbprz=0
>
On 27 February 2016 at 06:12, Martin K. Petersen
wrote:
>
> "A MAXIMUM WRITE SAME LENGTH field set to zero indicates that the device
> server does not report a limit on the number of logical blocks that it
> allows to be unmapped or written in a single WRITE SAME command."
>
> I.e. that parameter
No I mean I no longer thinks that this condition needs to be inverted.
I just THOUGHT that !scsi_get_vpd_page is true if it DIDN'T get the
page.
On 27 February 2016 at 04:57, James Bottomley
wrote:
> On Sat, 2016-02-27 at 04:32 +0800, Tom Yan wrote:
>> Oh I made a mistake on
Oh I made a mistake on this one then.
Since I send it with another patch, should I resend that alone?
On 27 February 2016 at 04:16, James Bottomley
wrote:
> On Sat, 2016-02-27 at 04:07 +0800, tom.t...@gmail.com wrote:
>> From: Tom Yan
>>
>> Signed-off-by: Tom Yan
>&
have been talking about cases when the Maximum
Write Same Length reported in the Block Limit VPD is 0.
On 27 February 2016 at 04:07, wrote:
> From: Tom Yan
>
> Example:
>
> [root@localhost ~]# sg_opcodes /dev/sdb > /dev/null
> Report supported operation codes: Illegal re
I have a WD My Passport that has a SES device with it:
[tom@localhost ~]$ lsscsi -g
...
[7:0:0:0]diskWD My Passport 083A 1065 /dev/sdc /dev/sg3
[7:0:0:1]enclosu WD SES Device 1065 - /dev/sg4
which is a Simple Subenclosure, as documented in SES-3 (Rev. 11
Currently the scsi disk driver would "assume write through" (i.e. no
writeback cache on the disk) when the disk fail to report the
availablity of writeback cache (e.g. no caching mode page), then spam
an error through kernel messages.
Although there is a switch to change that "assumption", but it'
Would it be better to only report when the value is smaller than
256MiB instead of "capping" it?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 25 June 2015 at 09:15, Martin K. Petersen wrote:
>
> The drive reporting deterministic zero is not enough. It needs to be
> explicitly whitelisted before we report discard_zeroes_data=1.
>
Not sure what you mean here. I just meant I don't think the "lower
limit" thing I am experiencing is rela
Isn't that even more of a firmware bug than the problem I
have? If they blow up even with single range with less then 65535
blocks addressed, wouldn't they blow up anytime if they do filesystem
TRIM?
On 24 June 2015 at 10:55, Martin K. Petersen wrote:
>>>>>> "To
First of all let me add another "statistic" about the issue:
[tom@localhost ~]$ sudo shred -n 1 /dev/sda3
[tom@localhost ~]$ sudo blkdiscard /dev/sda3
[tom@localhost ~]$ sudo hexdump /dev/sda3 | wc -l
310635
[tom@localhost ~]$ sudo hexdump /dev/sda3 | pcregrep -M '
000
On 24 June 2015 at 01:03, Martin K. Petersen wrote:
>
> It don't know what these "lower limits" you are talking about are.
>
[tom@localhost ~]$ sudo shred -v -n 1 /dev/sda3
[tom@localhost ~]$ sudo blkdiscard -l 512 /dev/sda3
[tom@localhost ~]$ sudo hexdump -n 4096 /dev/sda3 | head
000 58c7 f
On 23 June 2015 at 23:36, Martin K. Petersen wrote:
>
> You haven't given us any reason to. We are not aware of any ATA drives
> that put constraints on the range block count.
>
What I have been doing is trying to show you example of those
constraints. When I talked about the block count limit of
Still, I wonder if the kernel should allow the user to configure the
real granularity and send ATA commands that are rounded off by it
(which works just like --step in blkdiscard). For example,
(64 * 65535) % 8 = 0
but
65535 % 8 = 7
So the block count limit for the ATA commands would be 65535 -
wouldn't "falsify"
anything for devices which do provide some VPD(s). : \
Another P.S.: I made a mistake in one of my last mails. 65535 is two
bytes, not four bytes. : /
On 21 June 2015 at 20:36, Tom Yan wrote:
> https://git.kernel.org/cgit/linux
spec? Or is it just like a
draft/example which people can only consider it as "may work"?
On 21 June 2015 at 16:05, Tom Yan wrote:
> By the way do you think it could be a bug of libata's SATL anyway?
> Like perhaps it should break a single unmap request to multiple ATA
&g
5).
On 21 June 2015 at 15:03, Tom Yan wrote:
> On 21 June 2015 at 08:20, Martin K. Petersen
> wrote:
>> It is a SATA-attached drive, it has no block limits VPD. What you are
>> seeing is information prepared by libata's SATL.
>>
>> Because if the vendor got
On 21 June 2015 at 08:20, Martin K. Petersen wrote:
> It is a SATA-attached drive, it has no block limits VPD. What you are
> seeing is information prepared by libata's SATL.
>
> Because if the vendor got these trivial values wrong there is little to
> no chance that they implemented discard corre
Today I check if blkdiscard really does a full device trim/wipe for my
Intel 530 SSD (240gb) with hexdump. I end up found that it fail to do
so because it report garbage info on its block limits VPD.
[tom@localhost ~]$ sudo sg_vpd -p 0xb0 /dev/sda
Block limits VPD page (SBC):
Write same non-zero
k that vendors would do better on VPDs in the
future.
On 19 June 2015 at 05:01, Martin K. Petersen wrote:
>>>>>> "Tom" == Tom Yan writes:
>
> Tom> No I put it in the wrong way. What I meant was "sd vs md". For
> Tom> example, couldn't the s
1 - 100 of 105 matches
Mail list logo
