On Tue, Jun 12, 2012 at 9:49 PM, Yaniv Gardi <ygardi@xxxxxxxxxxxxxx> wrote: > > > = > -----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. > 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 > But you still need to invoke HPI when there are regular requests received after issuing SANITIZE. You might suggest to use only in carrier labs, but that doesn't exclude other uses. > > = > > 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 ? > I understand now :-). From what you are implying, SANITIZE is a convenient way of saying "ERASE all the TRIM'ed and DISCARD'ed sectors, I don't remember/care which ones.." Which makes a good case for your patches. If possible, it would be good to include the change to invoke HPI when a request is received while SANITIZE is in progress, but that can be done at a later point as well.. > > = > > > = > > 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(-) = > > -- 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
