RE: [PATCH v6 0/2] *** adding and exposing SANITIZE capability to the user space via a unique IOCTL ***

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Yaniv
> -----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?

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

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


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux