Re: OT: Festplatte löschen

From: Bernd Walter <ticso(at)cicely7.cicely.de>
Date: Thu, 20 Sep 2012 17:42:03 +0200

On Wed, Sep 19, 2012 at 04:04:30PM +0200, Sascha Holzleiter wrote:
> On 2012-09-19 13:27, naddy(at)mips.inka.de wrote:
> >Sascha Holzleiter <sascha(at)root-login.org> wrote:
> >
> >>> MRAM.
> >>> http://www.channelregister.co.uk/2012/01/23/dell_lsi_mram/
> >>
> >>http://www.lsi.com/about/newsroom/Pages/20110719pr.aspx
> >>Hier gibt es die hauseigene Meldung mit Links zu den Produkten.
> >
> >"NAND flash memory". Wo siehst du dort MRAM?
>
> Nirgends. Bernd sprach ebenfalls vom Caching per Flashspeicher daher
> der Einwurf.
> Man kann das Haar natürlich jetzt spalten... ;)

MRAM und auch die konkurierende FRAM-Technologie haben durchaus
einige erwähnenswerte Fortschritte gemacht, die von einfachen
Configspeichern weg gehen, sodass es mir nicht abwegig erscheint,
wenn Controller damit arbeiten.
Beide haben nichtflüchtigen Speicher, der SRAM ähnlich benutzt
wird und haben eine sehr hohe Schreibgeschwindigkeit.
Preislich denke ich aber, dass es so schnell keine Konkurenz zu
RAM oder Flash sein dürfte und eher spezielle Aufgaben erfüllt,
wie kleiner Cache bei billigen Controllern ohne Akku, oder
nur Statusverwaltung oder aber für teure Controller.
Bislang sind MRAM und FRAM eher im Bereich von einigen Bytes oder
kBytes vorzufinden, aber wie gesagt: Die Technik erlaubt inzwischen
durchaus auch einige MB.
Mit Flash und RAM hingegen sind auch GB möglich, nur hat Flash
Verschleiß und RAM braucht eine Batterie, die ebenfalls verschleißt.
Mir ist MRAM auf einem Controller noch nicht unter gekommen, aber
für abwegig halte ich das nicht und wenn nicht jetzt, dann garantiert
in der zukunft - die Technik passt super in die Aufgabe.

SSD mit MRAM zur Verwaltung wäre auch mal eine coole Kombination.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 20 Sep 2012 - 17:43:00 CEST

search this site