Oliver Brandmueller wrote:
> Oliver Fromme wrote:
> > ad(4) sendet in dem Fall das "CFA Erase"-Kommando (siehe
> > ata-disk.c), was etwas Ähnliches ist wie TRIM, aber nicht
> > ganz dasselbe. Die CFA-Kommandos gibt es schon länger
> > als TRIM; sie stammen noch aus der CompactFlash-Welt.
>
> Tun sie am Ende ähnliches bei einer modernen SSD?
Gute Frage. Vermutlich tun sie das (würde zumindest Sinn
ergeben), aber solche Details kann einem wohl nur der Her-
steller bzw. der Programmierer der Firmware verraten.
> > ATACAM brauchst Du übrigens nicht, ahci genügt völlig.
> > Du erhältst dann nur noch die ada*-Devices; ad* bekommt
> > man gar nicht mehr zu Gesicht. Das würde ich grundsätz-
> > lich für alle Neuinstallationen mit SATA-Festplatten
> > empfehlen (und es kann auch sinnvoll sein, bestehende
> > Installationen auf ahci + ada umzustellen), allein schon
> > um in den Genuss von NCQ zu kommen. Und dann klappt's
> > auch mit TRIM.
>
> Ja, wenn die Hardware neu genug für AHCI ist... Ich hatteg erade eine
> unterm Hintern, die AHCI nicht konnte.
Tatsächlich? Aus dem Stegreif wüsste ich keinen SATA-Con-
troller, der nicht AHCI-kompatibel wäre. Allerdings kann
es sein, dass gewisse alte Mainboards (wohl noch aus der
ersten SATA-Generation) per Default nur den IDE-Emulations-
modus einschalten und noch keine Möglichkeit im BIOS-Setup
anbieten, auf AHCI umzuschalten.
> Die nächste spannende Frage, die sich mir stellt: Wie sieht es denn dann
> mit gmirror aus? Wenn ich einen gmirror aufbaue wird ja die gesamte
> (zweite) SSD einmal überschrieben - das wäre doch dann aber eigentlich
> letztlich sehr kontraproduktiv?
Das ist in der Tat suboptimal. Wie "sehr" es kontraproduk-
tiv ist, hängt von vielen Faktoren ab. Ich habe z.B. eine
(einzelne) SSD ganz ohne TRIM im Einsatz, aber da nur wenig
darauf geschrieben wird (es ist die System-"Platte"), macht
es praktisch nichts aus.
> gmirror hat ja seinerseits keine Ahnung vom darüberliegenden
> Filesystem.
Ja, es wäre nützlich, wenn gmirror TRIM durchreichen würde.
Spontan würde ich sagen, dass das trivial zu implementieren
wäre (vielleicht ist bisher nur niemand auf die Idee gekom-
men), aber vielleicht steckt da der Teufel im Detail.
> Das hieße dann aber, daß TRIM support von UFS nur
> da Sinn macht, wo das UFS direkt auf dem Device rödelt - was
> im Rahmen des Dauerbetriebs und vorsorglichen Austauschs einer Platte
> allerdings wieder problematisch wäre?
Wenn es um High-Availability im Server-Umfeld geht, ja, da
gebe ich Dir recht. Aber wie gesagt, es kommt immer auf
den Einzelfall an, wie sehr sich das Fehlen von TRIM be-
merkbar macht. Es ist ja nicht so, dass die SSD dann
schneckenlahm wird. Man kann (kann!) halt nach einer
gewissen Zeit ein paar Prozente Schreibperformance ver-
lieren. Die Leseperformance bleibt völlig unbeeinflusst.
Man sollte auch bedenken, dass TRIM noch relativ neu ist
und es immer noch SSDs gibt, die dieses Kommando überhaupt
nicht unterstützen, und die trotzdem funktionieren. ;-)
> Um das also zu gewährleisten müßte man wohl eher mit einem
> ZFS arbeiten (welches ja keinen TRIM support hat)?
Da muss ich zugeben, dass ich nicht ganz auf dem laufenden
bin, was ZFS + TRIM betrifft. Möglich, dass das in Arbeit
ist.
Übrigens gibt es auch die Variante, einen gmirror aus einer
SSD und einer herkömmlichen Platte zu bilden. Das kann
durchaus Sinn ergeben: Lesezugriffe kommen von der SSD,
solange sie nicht ausfällt (per "gmirror -b prefer"), und
Schreibzugriffe werden auf beide durchgeführt. Bei einer
hohen Schreiblast ist das nicht so klug, da die Festplatte
dann das Gesamtgespann ausbremsen kann, aber bei geringer
bis mäßiger Schreiblast wird das vom Cache abgefedert und
fällt kaum ins Gewicht.
(Bezüglich TRIM hilft so eine Konstellation natürlich auch
nicht weiter.)
Gruß
Olli
-- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Mon 07 Mar 2011 - 22:40:58 CET