linux-kernel - Re: [RFC][PATCH] mmc: add an ioctl for erasing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4C039A1B.8040405@nokia.com>
Date:	Mon, 31 May 2010 14:14:35 +0300
From:	Adrian Hunter <adrian.hunter@...ia.com>
To:	Christoph Hellwig <hch@...radead.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] mmc: add an ioctl for erasing

Adrian Hunter wrote:
> Christoph Hellwig wrote:
>> On Mon, May 31, 2010 at 11:45:37AM +0300, Adrian Hunter wrote:
>>> Sorry for the slow reply, I have been away.
>>>
>>> Connecting erase to discard was rejected for performance reasons in 2008.
>>> Refer:
>>>
>>> 	http://thread.gmane.org/gmane.linux.file-systems/25378/focus=25606
>> The discard implementation changed a lot since those days.  Discard
>> requests now have their own request size limitation which is separate
>> form that for normal requests, and we also store the alignment
>> requirement for them separately.
>>
> 
> 
> I tested extensively at that time with all changes necessary to allow
> discards to produce MMC erases that work with maximum efficacy.  There was
> no performance benefit and operations like file deletion were much slower.
> 
> If connecting discard to MMC erase does not always improve performance, then
> many people will have to change their mount options to include nodiscard.
> Alternatively, if the connection is an optional configuration, then the
> ioctl won't work all the time.
> 
> The erase ioctl needs to be separate from discard, which means it can be
> made to support secure erase also.
> 

Looking at the code for BLKDISCARD, I saw BLKDISCARDZEROS which confirms
another reason that 'discard' is different to 'erase', which is that some
devices leave stale data in the discarded region i.e. no erase takes place.

So there are 2 ways that discard is slightly different semantically:
	1. discard is an optimisation - it does not have to happen whereas
	'erase' is like 'write', it is an error for it not to take place
	(if it is supported)
	2. discard does not guarantee to zero the discarded region

(A minor complication for some cards is that MMC erase will set the erased
region to all 1's or all 0's depending on the card)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/