all just a dm-crypt issue on handling multiple
bios created with next_bio (a bio chain)?
On 10 August 2017 at 07:27, Tom Yan <tom.t...@gmail.com> wrote:
> I haven't really tested but I was aware of the commit before I send my
> last email. It doesn't seem relevant to be honest, because it doesn't
I haven't really tested but I was aware of the commit before I send my
last email. It doesn't seem relevant to be honest, because it doesn't
change the fact that the inner loop wil only end if the whole request
has been looped over. So still one big bio.
There are a few things that seem
On 14 August 2016 at 17:00, Tom Yan <tom.t...@gmail.com> 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?
>
On 13 August 2016 at 04:56, Martin K. Petersen
<martin.peter...@oracle.com> wrote:
>>>>>> "Tom" == Tom Yan <tom.t...@gmail.com> writes:
>
> Tom,
>
>>> put_unaligned_be64(65535 * ATA_MAX_TRIM_RNUM / (sector_size / 512),
>>> [36]
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
On 13 August 2016 at 04:26, Martin K. Petersen
<martin.peter...@oracle.com> wrote:
>>>>>> "Tom" == Tom Yan <tom.t...@gmail.com> writes:
>
> Tom,
>
> Tom> I don't really follow. What would this BLK_MAX_BIO_SECTORS be? It
> Tom> doesn't a
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
On 12 August 2016 at 13:18, Tom Yan <tom.t...@gmail.com> wrote:
> On 12 August 2016 at 10:01, Martin K. Petersen
> <martin.peter...@oracle.com> wrote:
>>
>> Again, the point of max_hw_sectors and max_dev_sectors is to enforce the
>> hard limits of controller a
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
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), [36]);
>
> MAXIMUM WRITE
ould have probably used the bit shift
way instead.
On 11 August 2016 at 17:04, Shaun Tancheff <sh...@tancheff.com> wrote:
> On Thu, Aug 11, 2016 at 3:26 AM, <tom.t...@gmail.com> wrote:
>> From: Tom Yan <tom.t...@gmail.com>
>>
>> Currently we advertise
On 11 August 2016 at 11:37, Martin K. Petersen
<martin.peter...@oracle.com> wrote:
>>>>>> "Tom" == Tom Yan <tom.t...@gmail.com> writes:
>
> I don't agree with conflating the optimal transfer size and the maximum
> supported ditto. Sub
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
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
e:
> From: Tom Yan <tom.t...@gmail.com>
>
> We should just let the scsi driver (hosts.c) call the function. It
> has better heuristic anyway (i.e. use SCSI_DEFAULT_MAX_SECTORS as
> fallback when max_sectors is not set).
>
> diff --git a/drivers/ata/libata-scsi.c b/drive
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
16 matches
Mail list logo