Add MMC erase and secure erase
in [Kernel]
|
Prev: fs: make sure to invalidate pages if we fall back on buffered reads
Next: [PATCH] input: bcm5974: Set the average number of events per MT event packet
From: Christoph Hellwig on 14 Jun 2010 04:20 On Sun, Jun 13, 2010 at 01:01:34PM +0300, Adrian Hunter wrote: > Hi > > Add ability to do MMC erase and secure erase operations from userspace, > using the BLKDISCARD ioctl and a newly created BLKSECDISCARD ioctl. Have you done any measurement if the use of the block layer changes performance of the discard requests for you? I'd really prefer to send down the secure erase that way, too. This could easily be done by having a DISCARD_SECURE rw flag, which just ORs another flag into the request type field. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Adrian Hunter on 14 Jun 2010 07:20 Christoph Hellwig wrote: > On Sun, Jun 13, 2010 at 01:01:34PM +0300, Adrian Hunter wrote: >> Hi >> >> Add ability to do MMC erase and secure erase operations from userspace, >> using the BLKDISCARD ioctl and a newly created BLKSECDISCARD ioctl. > > Have you done any measurement if the use of the block layer changes > performance of the discard requests for you? No. For my purposes there will be only 1 discard request for the entire device which will take several minutes to process, so block layer performance is not a factor. > I'd really prefer to > send down the secure erase that way, too. This could easily be done > by having a DISCARD_SECURE rw flag, which just ORs another flag into > the request type field. Needs a bio flag, a request flag, setup the request flag based on the bio flag, prevent merging secure and non-secure discards, prevent drivers doing non-secure discards for secure discards. Seems like a lot of little changes for something that no one wants. Shouldn't it wait for someone to need it first? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 14 Jun 2010 07:30
On Mon, Jun 14, 2010 at 02:10:06PM +0300, Adrian Hunter wrote: > Needs a bio flag, a request flag, setup the request flag based on the > bio flag, prevent merging secure and non-secure discards, prevent drivers > doing non-secure discards for secure discards. > > Seems like a lot of little changes for something that no one wants. > Shouldn't it wait for someone to need it first? I know that some people have asked for this. But if you want to keep it in the driver for now that's fine to me. But in that case please: (a) make it entirely driver private and leave no traces of it in the block layer (b) split it into a separate patch from the discard support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |