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