> -----Original Message----- > From: Yaniv Gardi [mailto:ygardi@xxxxxxxxxxxxxx] > Sent: Wednesday, June 13, 2012 12:20 AM > To: Dong, Chuanxiao; 'S, Venkatraman' > Cc: linux-mmc@xxxxxxxxxxxxxxx; merez@xxxxxxxxxxxxxx > Subject: RE: [PATCH v6 0/2] *** adding and exposing SANITIZE capability to the user > space via a unique IOCTL *** > > > > = > -----Original Message----- > = > From: Dong, Chuanxiao [mailto:chuanxiao.dong@xxxxxxxxx] = > Sent: Monday, > June 11, 2012 6:04 AM = > To: Yaniv Gardi; 'S, Venkatraman' > = > Cc: linux-mmc@xxxxxxxxxxxxxxx; merez@xxxxxxxxxxxxxx = > Subject: RE: > [PATCH v6 0/2] *** adding and exposing SANITIZE capability to = > the user space > via a unique IOCTL *** = > = > Hi Yaniv Hi Chuanxiao, > > = > > -----Original Message----- > = > > From: linux-mmc-owner@xxxxxxxxxxxxxxx = > > > [mailto:linux-mmc-owner@xxxxxxxxxxxxxxx] On Behalf Of Yaniv Gardi = > > Sent: > Sunday, June 10, 2012 9:49 PM = > > To: 'S, Venkatraman' > = > > Cc: linux-mmc@xxxxxxxxxxxxxxx; merez@xxxxxxxxxxxxxx = > > Subject: RE: > [PATCH v6 0/2] *** adding and exposing SANITIZE = > > capability to the user space > via a unique IOCTL *** = > > = > > First, the REQ_SECURE + REQ_DISCARD are used > for specific sector/s. > = > > SANITIZE is a generic command that erase all unmapped sectors. > = > If a lot of sectors, like 4GBytes, have been marked as unmapped, how long = > > will SANITIZE command take to erase all of them? Will it cause a long time = > delay > for other requests? > > The answer is YES and NO. > Yes - the SANITIZE might take a long time (few minutes) and thus there is a special > timeout for this request. If the timeout happens, how could driver to handle this timeout event? Will SANITIZE operation continue or failed at somewhere? > NO - it should not cause delay, since SANITIZE request is not intended to be issued > as part of operational functioning of the card, but On the carrier labs for example, > by a dedicated user application > > > = > > Second, secure erase for a specific sector (SECURE TRIM) is no longer > = > supported. > = > REQ_SECURE can still erase a specific sector in current MMC driver. > = > If the device support SANITIZE, driver will first use ERASE/TRIM command > = > to mark unmapped sectors, and then issue SANITIZE command to erase > = > them. eMMC4.5 specification has said clearly that ERASE/TRIM command > = > can move the mapped host address range to the unmapped host address > = > range. > = > If the device cannot support SANTIZE, driver will use secure erase/trim > = > command directly. > = > > The whole point of using SANITIZE is to separate the ERAER/TRIM/DISCARD > requests from the SANITIZE operation > For example - > A card can get many DISCARD, ERASE and TRIM requests, and weeks after can > perform SANITIZE. > Also, an important note is to clarify that SANITIZE doesn't get START SECTOR > and NUMBER OF SECTORS. > It a generic request working on the entire card. > > Is that helping in anyway ? As current implementation, driver will only do one operation for eMMC card, and the order is DISCARD, TRIM and then ERASE. So if a card support DISCARD, the DISCARD only. If not but support TRIM, TRIM only. If also not, ERASE only. And SANITIZE cannot erase the block operated by DISCARD command. So to implement your scenario, how about only add mmc_blk_issue_sanitize_rq() for REQ_SANITIZE but not touch mmc_blk_issue_secdiscard_rq()? With your changes in mmc_blk_issue_secdiscard_rq(), eMMC4.5 device will be failed to operate secure trim/erase for REQ_SECURE request. Thanks Chuanxiao > > > = > > > = > > Anyhow, SANITIZE replaces the need to issue REQ_SECURE as part of the > = > > REQ_DISCARD request. In this way DISCARD request finishes much faster > = > > (order of > = > > magnitude) and thus improves system performance. When the NVM > = > content > = > > must be erased, the user may use SANITIZE to erase all unmapped > = > sectors. > = > > > = > > An example of usage is refurbished devices in which the carrier wants > = > > to erase NVM content (since the user used only DISCARDs), in this case > = > > the a SANITIZE operation will be triggered in the carrier labs from a > = > > dedicated application through IOCTL that goes directly to the device. > = > > Note that no change to the FS is required for such operation. > = > I think the usage you posted here is just what REQ_SECURE implemented. > = > REQ_SECURE will first unmapped the mapped host address and then issue > = > SANITIZE command to erase the contents. > = > > = > Thanks > = > Chuanxiao > = > > > = > > Thanks, > = > > Yaniv > = > > > = > > = > -----Original Message----- > = > > = > From: S, Venkatraman [mailto:svenkatr@xxxxxx] = > Sent: Friday, > = > > June 08, 2012 > = > > 2:30 PM = > To: Yaniv Gardi = > Cc: linux-mmc@xxxxxxxxxxxxxxx; > = > > merez@xxxxxxxxxxxxxx = > Subject: Re: [PATCH v6 0/2] *** adding and > = > > exposing SANITIZE capability to = > the user space via a unique IOCTL > = > > *** = > = > On Thu, Jun 7, 2012 at 8:08 PM, Yaniv Gardi > = > <ygardi@xxxxxxxxxxxxxx> = > wrote: > = > > = > > *** adding and exposing SANITIZE capability to the user space > = > > via a = > > unique IOCTL *** = > = > Well, is this really needed ? As > = > > I understand, SANITIZE is identical to = > REQ_SECURE + REQ_DISCARD. > = > > = > Mapping the device function to an existing attribute is more easy > = > > that = > creating the whole plumbing around SANITIZE, just because it > = > exists. > = > > = > Apart from the IOCTL, it would be useful to find if any file > = > > systems want to = > use this, and it is any way more friendly than > SECURE > = > + DISCARD. > = > > = > > = > > = > > > = > > = > > changes patch v6: > = > > = > > fixed some code review comments > = > > = > > added timeout dependency for CMD6 when issueing the sanitize = > > = > > command. > = > > = > > > = > > = > > changes patch v5: > = > > = > > added BUG_ON() where needed > = > > = > > > = > > = > > changes patch v4: > = > > = > > removed a few debug printouts > = > > = > > > = > > = > > changes patch v3: > = > > = > > split the patch into 2 commits - block and mmc/card added > = > > capability = > > MMC_CAP2_SANITIZE to mmc controller = > > = > > Yaniv > = > Gardi (2): > = > > = > > block: ioctl support for sanitize in eMMC 4.5 = > > mmc: card: > = > > Adding support for sanitize in eMMC 4.5 = > > = > > block/blk- > = > core.c > = > > | 18 > = > > +++++++++-- = > > block/blk-lib.c | 51 > = > > +++++++++++++++++++++++++++++++ = > > block/blk-merge.c | > = > > +++++++++++++++++++++++++++++++ 6 > = > > ++++ = > > block/elevator.c | 41 > ++++++++++++++++++++++++- > = > > = > > block/ioctl.c | 9 +++++ = > > > = > > drivers/mmc/card/block.c | 72 = > > > = > > ++++++++++++++++++++++++++++++++------------ > = > > = > > drivers/mmc/card/queue.c | 10 +++++- = > > > = > > include/linux/blk_types.h | 5 ++- = > > include/linux/blkdev.h > = > > | 3 ++ = > > include/linux/fs.h | 1 + = > > > = > > include/linux/mmc/host.h | 1 + = > > kernel/trace/blktrace.c | > = > > 2 + = > > 12 files changed, 191 insertions(+), 28 deletions(-) = > > > = > > = > > -- = > > 1.7.6 = > > -- = > > Sent by a consultant of the > = > > Qualcomm Innovation Center, Inc. > = > > = > > The Qualcomm Innovation Center, Inc. is a member of the Code > = > > Aurora = > > Forum = > > -- = > > 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 > = > > > = > > -- > = > > 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 -- 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
