Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

2015-10-28 Thread Jeff Moyer
Ulf Hansson writes: > I am not sure if this issue is the same as been discussed earlier on > the mmc list regarding "discard/erase". > > Anyway, there have been several attempts to fix bugs related to this. > One of these discussion kind of pointed out a viable solution, but > unfortunate no patc

Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

2015-10-21 Thread Grant Grundler
On Tue, Oct 20, 2015 at 11:57 AM, Jeff Moyer wrote: > Hi Grant, > > Grant Grundler writes: > >> Ping? Does no one care how long BLK_SECDISCARD takes? >> >> ChromeOS has landed this change as a compromise between "fast" (<10 >> seconds) and "minimize risk" (~90 seconds) for a 23GB partition on >>

Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

2015-10-21 Thread Grant Grundler
On Wed, Oct 21, 2015 at 2:00 AM, Ulf Hansson wrote: To put a few more numbers on the "chunk size vs perf": 1EG (512KB) -> 44K commands -> ~20 minutes 32EG (16MB) -> 1375 commands -> ~1 minute 128EG (64MB) -> 344 commands -> ~30 seconds 8191EG (~4GB) -> 6 commands ->

Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

2015-10-21 Thread Ulf Hansson
ia a > userspace utility such as mkfs, online discard via some file system > mounted with -o discard, or something else? Finally, can you post > binary blktrace data somewhere for the slow case? > > Thanks! > Jeff > > > > >> On Mon, Sep 28, 2015 at 2:45 PM, Grant Grundler &

Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

2015-10-20 Thread Jeff Moyer
st binary blktrace data somewhere for the slow case? Thanks! Jeff > On Mon, Sep 28, 2015 at 2:45 PM, Grant Grundler wrote: >> [resending...I forgot to switch gmail back to text-only mode. grrrh..] >> >> ------ Forwarded message -- >> From: Grant Grundle

Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

2015-10-20 Thread Grant Grundler
grrrh..] > > -- Forwarded message -- > From: Grant Grundler > Date: Mon, Sep 28, 2015 at 2:42 PM > Subject: Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE > To: Grant Grundler > Cc: Jens Axboe , Ulf Hansson > , LKML , > "linux-mmc@vger.kern

Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

2015-09-29 Thread Gwendal Grignou
On Mon, Sep 28, 2015 at 2:45 PM, Grant Grundler wrote: > [resending...I forgot to switch gmail back to text-only mode. grrrh..] > > -- Forwarded message -- > From: Grant Grundler > Date: Mon, Sep 28, 2015 at 2:42 PM > Subject: Re: RFC: 32-bit __data_len and REQ_DI

Fwd: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

2015-09-28 Thread Grant Grundler
[resending...I forgot to switch gmail back to text-only mode. grrrh..] -- Forwarded message -- From: Grant Grundler Date: Mon, Sep 28, 2015 at 2:42 PM Subject: Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE To: Grant Grundler Cc: Jens Axboe , Ulf Hansson , LKML , "

Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

2015-09-24 Thread Grant Grundler
Some followup. 1) I re-read the original proposals to support TRIM/DISCARD here: https://lwn.net/Articles/293658/ Note the original API asked for "unsigned nr_sects" - which is essentially what my proposed hack does. I'll need to find out where/why this got dropped. 2) I've been able to tes

RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

2015-09-22 Thread Grant Grundler
Jens, Ulf, I've run into a basic issue: BLK_SECDISCARD takes 15-35 minutes perform a secure erase of ~23GB (mostly empty) partition on a 32GB eMMC part (happens with two vendors). One of the vendors says it should take less than 60 seconds. I've confirmed erasing 2GB takes only ~6 seconds - so the