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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200905251104.47550.wolfgang.mues@auerswald.de>
Date:	Mon, 25 May 2009 11:04:47 +0200
From:	Wolfgang Mües <wolfgang.mues@...rswald.de>
To:	"David Brownell" <david-b@...bell.net>
Cc:	"Pierre Ossman" <pierre@...man.eu>,
	"Matt Fleming" <matt@...sole-pimps.org>,
	"Pierre Ossman" <drzeus@...eus.cx>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Mike Frysinger" <vapier.adi@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mmc_spi: use EILSEQ for possible transmission errors

David,

Am Donnerstag, 21. Mai 2009 schrieb David Brownell:
> On Wednesday 20 May 2009, Pierre Ossman wrote:
> > >		 Remember that the
> > > firmware in the card can leverage "that's erased" knowledge for
> > > things like wear leveling.  SSDs and other storage devices would
> > > likewise benefit from such knowledge.  I'm quite certain there's
> > > been discussion about adding support for that in the block layer.
> >
> > It's already in AFAIK. I even had code for hooking it up to mmc_block.
> > But it didn't produce any measurable results so I never merged it.
>
> I'd expect the results would take time to show.  As in, they would
> facilitate wear leveling logic, which may be difficult to measure
> except by testing various cards to destruction ... even for vendors
> that *do* have decent wear leveling.  :)

Can someone please explain for me the purpose and the implementation of this 
wear level logic in block.c?

I can not see why a sector erase and the sector erase result codes of a MMC/SD 
card can be used to get any usefull information about wear leveling in the 
card. The mapping of physical to logical blocks is not reported by the card, 
and the number of erase cycles for each block is also not reported. SO how 
can the host be able to optimize the wear leveling?

As far as I can see, the best wear level handling for MMC/SD cards is to 
optimize the size of the chunks of data to write. I have posted a patch
(mmc_spi: speedup for slow cards, less wear-out), and it was accepted by 
Pierre at 11th of april.

best regards
 
i. A. Wolfgang Mües
-- 
Auerswald GmbH & Co. KG
Hardware Development
Telefon: +49 (0)5306 9219 0
Telefax: +49 (0)5306 9219 94 
E-Mail: Wolfgang.Mues@...rswald.de
Web: http://www.auerswald.de
 
--------------------------------------------------------------
Auerswald GmbH & Co. KG, Vor den Grashöfen 1, 38162 Cremlingen
Registriert beim AG Braunschweig HRA 13289
p.h.G Auerswald Geschäftsführungsges. mbH
Registriert beim AG Braunschweig HRB 7463
Geschäftsführer: Dipl-Ing. Gerhard Auerswald
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ