On 2018/5/28 16:51, Christoph Hellwig wrote:
On Mon, May 28, 2018 at 04:05:38PM +0800, Shawn Lin wrote:
On 2018/5/28 15:57, Christoph Hellwig wrote:
On Mon, May 28, 2018 at 03:49:26PM +0800, Shawn Lin wrote:
card->erased_byte read from SCR(for SD cards) or EXT_CSD[181](for eMMC)
indicates whether the TRIM or ERASE make the erased data content zeros,
but DISCARD doesn't. Use the fact to implement REQ_OP_WRITE_ZEROES.
I don't have the mmc spec in front of my, but the ATA/SCSI and NVMe
equivalents all have the problem that if the device decideds to not
deallocate the blocks it can leave the old data in place. Can you
confirm that MMC gurantees that this is not the case?
Yes. Quoting from JESD85-B51 spec for eMMC, section 6.6.10 TRIM,
"The contents of a write block where the trim function has been applied
shall be '0' or '1' depending on different memory technology. This value
is defined in the EXT_CSD.". But 6.6.12 Discard says "The
contents of a write block where the discard function has been applied
shall be ‘don’t care’After discard operation, the original data may
be remained partially or fully accessible to the host dependent on
device. The portions of data that are no longer accessible by the host
may be removed or unmapped just as in the case of TRIM. The device will
decide the contents of discarded write block."
Apart from the mandatory requirement in spec, I confirmed this with
several device vendors as well, in the past.
So don't we need to check that the device actually supports the TRIM
operation (that is call mmc_can_trim()) before setting
mmc_can_erase() could help, as it, ERASE command, also guarantees the
data to be zeros after erased. And that checking is done before we set
max_write_zeroes_sectors.
drivers/mmc/core/queue.c
364 if (mmc_can_erase(card))
365 mmc_queue_setup_discard(mq->queue, card);
max_write_zeroes_sectors? Also you probably need a function different
from mmc_calc_max_discard to calculate max_write_zeroes_sectors given
that the different methods seem to have different limits.
At this point, we needn't. The limitation of ERASE/TRIM/DISCARD for mmc
are the same. And mmc_calc_max_discard already do the right thing IMHO.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
