Re: FreeBSD auf SSD

Roland Behme wrote:
> Oliver Fromme wrote:
> > - Bei SATA-Platten (SSDs und "normale"): ahci(4) + ada(4)
> > statt ata(4) + ad(4) verwenden. Dann kommt man in den
> > Genuss von NCQ und anderen Verbesserungen.
>
> Wenn ich das richtig verstanden habe, reicht dazu ein
> ahci_load="YES" in der loader.conf, richtig?

Ich fürchte, Du brauchst auch ada(4), was es derzeit nicht
als Modul zu geben scheint. Ich habe bei mir ahci(4) und
ada(4) statisch in den kernel compiliert. Ist aber auch
nicht schwer. Kurzes Kochrezept (als root, System-Source-
code muss installiert sein):

# cd /sys/i386/conf (oder /sys/amd64/conf, je nachdem)
# cp GENERIC MEINKERNEL
# echo device ahci >> MEINKERNEL
# echo device ada >> MEINKERNEL
# cd /usr/src
# make kernel KERNCONF=MEINKERNEL
# shutdown -r now

Das ist alles. Statt MEINKERNEL kannst Du ihn natürlich
auch anders nennen.

> An ad6 bis ad14 habe ich ein RaidZ aus 5 Platten. Nach einem
> zpool export/import sollte sich ZFS nicht daran stören, dass
> die Platten mit ahci/ada andere Devicenodes haben, oder?

Öhm, gute Frage. Theoretisch sollte das gehen. Ich habe
Umstellungen von ad(4) auf ada(4) bisher nur mit UFS ge-
macht; dort muss man die /etc/fstab ändern, sofern man
noch mit physikalischen Devices (nicht Labels) arbeitet.
Wenn man Labels verwendet, muss man gar nichts umstellen.

> > - Dateisysteme im Falle von UFS/UFS2 mit -b 32768 -f 4096
> > anlegen (Blockgröße 32 KB, Fragmentgröße 4 KB).
>
> Welche Vorteile hat das?

Viele (die meisten?) SSDs haben eine interne Zellengröße
von 4 KB. Das bedeutet, dass der Flash-Controller bei
Schreibzugriffen nur in Einheiten von 4 KB arbeiten kann.
Würde man nur 2 KB schreiben (die aktuelle Default-Frag-
mentgröße bei UFS2), müsste der Controller zunächst die
ganze 4-KB-Zelle lesen, löschen, und mit neuem Inhalt
wieder schreiben. Das ist natürlich nicht so effizient.
Setzt man die Fragmentgröße dagegen auf 4 KB, muss der
Controller den alten Inhalt der Zellen nicht lesen.

Ähnliches gilt für die neueren Festplatten >= 2 TB, die
intern ebenfalls mit 4-KB-Sektoren arbeiten, z.B. die
Samsung EARS.

Davon abgesehen ist 4 KB auch die Page-Size bei i386 und
amd64, weshalb eine ebenso große Fragmentgröße gewisse
Vorteile für das VM-System hat.

Einziger Nachteil ist, dass man eine gewissen Verschnitt
bei der Platzbelegung hat: Weil die kleinste belegbare
Einheit 4 KB ist, belegt eine Datei, die nur 100 Bytes
groß ist, trotzdem 4 KB Platz im Dateisystem. Das macht
sich insbesondere dann bemerkbar, wenn man viele kleine
Dateien hat. Andererseits ist das zu einer Zeit, wo
Festplattengrößen in TB gemessen werden, nicht mehr so
relevant. Um's mal zu verdeutlichen: In 1 TB passen
4 KB ca. 250 Millionen mal hinein. Auf meinem Rechner
hier befinden sich gerade mal 250 Tausend Dateien (inkl.
zwei src-Trees, ein obj-Tree und der Ports-Collection),
d.h. der maximale Verschnitt im worst-case wäre 0,1%.

> > TRIM-Support leistet
> > das theoretisch auch, aber den gibt es momentan nur in
> > 9-current (und ich würde ihn auch nur als experimentell
> > einstufen).
>
> Achso, dann kann FreeBSD 8.x noch gar kein TRIM?

Richtig.

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
Blogging:  Never before have so many people
with so little to say said so much to so few.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message