headers
Oliver Brandmueller | 7 Mar 2011 16:01

Re: FreeBSD auf SSD

Hallo,

On Tue, Feb 15, 2011 at 06:32:28PM +0100, Oliver Fromme wrote:
>  > bringt nichts derartiges zutage. Heißt das, ohne ATACAM kein TRIM oder 
>  > fehlt mir da nur der Weg das anzuzeigen?
> 
> 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?

> 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.

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? gmirror hat ja seinerseits keine Ahnung 
vom darüberliegenden Filesystem. Das hieße dann aber, daß TRIM support
(Continue reading)

Permalink | Reply | 1 comment |
headers
Oliver Fromme | 7 Mar 2011 22:40
Picon

Re: FreeBSD auf SSD

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthias Teege | 11 Mar 2011 09:38
Picon
Favicon

crosscompile FreeBSD i386

Hallo,

ich habe einen Buildserver unter FreeBSD 8.2/amd64. Jetzt habe ich 
mit:

make TARGET=i386 TARGET_ARCH=i386 buildworld 
make TARGET=i386 TARGET_ARCH=i386 buildkernel 

eine i386 Version gebaut und per NFS exportiert.

Auf dem Klient habe ich /usr/src und /usr/obj gemountet und 
folgendes ausgeführt:

cd /usr/src
setenv MAKEOBJDIRPREFIX /usr/obj/i386
make TARGET=i386 TARGET_ARCH=i386 installkernel

Das schlägt fehl, weil 
"/usr/obj/i386/usr/src/tmp/legacy/usr/bin/install" verwendet wird, 
in meinem Fall aber ein 64-bit executable ist.

# file /usr/obj/i386/usr/src/tmp/legacy/usr/bin/install
/usr/obj/i386/usr/src/tmp/legacy/usr/bin/install: ELF 64-bit LSB executable, x86-64, version 1
(FreeBSD), statically linked, for FreeBSD 8.2, not stripped

Das build enthält aber die i386 Programme.

# file /usr/obj/i386/usr/src/bin/cat/cat /usr/obj/i386/usr/src/bin/cat/cat: ELF 32-bit LSB
executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.2
(802502), not stripped
(Continue reading)

Permalink | Reply | 9 comments |
headers
Oliver Fromme | 11 Mar 2011 11:20
Picon

Re: crosscompile FreeBSD i386

Matthias Teege wrote:
 > ich habe einen Buildserver unter FreeBSD 8.2/amd64. Jetzt habe ich 
 > mit:
 > 
 > make TARGET=i386 TARGET_ARCH=i386 buildworld 
 > make TARGET=i386 TARGET_ARCH=i386 buildkernel 
 > 
 > eine i386 Version gebaut und per NFS exportiert.
 > 
 > Auf dem Klient habe ich /usr/src und /usr/obj gemountet und 
 > folgendes ausgeführt:
 > 
 > cd /usr/src
 > setenv MAKEOBJDIRPREFIX /usr/obj/i386
 > make TARGET=i386 TARGET_ARCH=i386 installkernel

Das funktioniert leider nicht, weil beim Installieren Bina-
ries verwendet werden, die für den Build-Host gebaut wurden
(wie Du ja bemerkt hast).

Damit es funktioniert, musst Du genau umgekehrt vorgehen:
Den Client per NFS exportieren und auf dem Buildserver
mounten, und dort dann »make DESTDIR=... installkernel«
verwenden.

Es geht natürlich auch ganz ohne NFS:  Zunächst alles auf
dem Buildserver in ein temporäres Verzeichnis installieren
(»make DESTDIR=/... install...«), und dieses dann auf den
Client kopieren (per cpdup, cpio, tar, was auch immer).
(Continue reading)

Permalink | Reply | 8 comments |
headers
Matthias Teege | 11 Mar 2011 15:00
Picon
Favicon

Re: crosscompile FreeBSD i386

On Fri, 11 Mar 2011, Oliver Fromme wrote:

Hallo,

> Es geht natürlich auch ganz ohne NFS:  Zunächst alles auf
> dem Buildserver in ein temporäres Verzeichnis installieren
> (»make DESTDIR=/... install...«), und dieses dann auf den
> Client kopieren (per cpdup, cpio, tar, was auch immer).

also das gefällt mir am besten :-) Meinst Du so was wie:

build# cpdup -o -j0 /export/i386/ client:/

Ich habe es probiert und es geht (vermutlich Glück), sieht aber wie ein 
Holzhammer aus. Vermutlich ist es besser, erst den neuen Kernel zu 
kopieren und danach das Userland zu ersetzen.

Vielen Dank
Matthias
Permalink | Reply | 7 comments |
headers
Oliver Fromme | 11 Mar 2011 16:37
Picon

Re: crosscompile FreeBSD i386

Matthias Teege wrote:
 > Oliver Fromme wrote:
 > > Es geht natürlich auch ganz ohne NFS:  Zunächst alles auf
 > > dem Buildserver in ein temporäres Verzeichnis installieren
 > > (»make DESTDIR=/... install...«), und dieses dann auf den
 > > Client kopieren (per cpdup, cpio, tar, was auch immer).
 > 
 > also das gefällt mir am besten :-) Meinst Du so was wie:
 > 
 > build# cpdup -o -j0 /export/i386/ client:/

Ja, im Prinzip ...

 > Ich habe es probiert und es geht (vermutlich Glück), sieht aber wie ein 
 > Holzhammer aus. Vermutlich ist es besser, erst den neuen Kernel zu 
 > kopieren und danach das Userland zu ersetzen.

Ja, ganz so wie oben hätte ich mich's nicht getraut.  :-)

Aber wenn das Zielsystem idle ist, kann man wohl tatsäch-
lich Glück haben.  Auch Minor-Updates (8.x --> 8.y) sollten
in der Hinsicht relativ problemlos sein, weil sich in dem
Fall an der ABI normalerweise nichts ändert, d.h. es kommen
keine neuen Syscalls hinzu oder so.

Pech kann man bei einem Major-Update haben (7.x --> 8.y),
wenn Binaries vor dem neuen Kernel installiert werden, die
dann versuchen, Syscalls zu verwenden, die der laufende
(alte) Kernel noch nicht kennt.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bernd Walter | 11 Mar 2011 19:31
Picon

Re: crosscompile FreeBSD i386

On Fri, Mar 11, 2011 at 04:37:26PM +0100, Oliver Fromme wrote:
> Matthias Teege wrote:
>  > Oliver Fromme wrote:
>  > > Es geht natürlich auch ganz ohne NFS:  Zunächst alles auf
>  > > dem Buildserver in ein temporäres Verzeichnis installieren
>  > > (»make DESTDIR=/... install...«), und dieses dann auf den
>  > > Client kopieren (per cpdup, cpio, tar, was auch immer).
>  > 
>  > also das gefällt mir am besten :-) Meinst Du so was wie:
>  > 
>  > build# cpdup -o -j0 /export/i386/ client:/
> 
> Ja, im Prinzip ...
> 
>  > Ich habe es probiert und es geht (vermutlich Glück), sieht aber wie ein 
>  > Holzhammer aus. Vermutlich ist es besser, erst den neuen Kernel zu 
>  > kopieren und danach das Userland zu ersetzen.
> 
> Ja, ganz so wie oben hätte ich mich's nicht getraut.  :-)
> 
> Aber wenn das Zielsystem idle ist, kann man wohl tatsäch-
> lich Glück haben.  Auch Minor-Updates (8.x --> 8.y) sollten
> in der Hinsicht relativ problemlos sein, weil sich in dem
> Fall an der ABI normalerweise nichts ändert, d.h. es kommen
> keine neuen Syscalls hinzu oder so.
> 
> Pech kann man bei einem Major-Update haben (7.x --> 8.y),
> wenn Binaries vor dem neuen Kernel installiert werden, die
> dann versuchen, Syscalls zu verwenden, die der laufende
> (alte) Kernel noch nicht kennt.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Oliver Fromme | 13 Mar 2011 14:56
Picon

Re: crosscompile FreeBSD i386

Bernd Walter wrote:
 > Oliver Fromme wrote:
 > > Matthias Teege wrote:
 > > > Oliver Fromme wrote:
 > > > > Es geht natürlich auch ganz ohne NFS:  Zunächst alles auf
 > > > > dem Buildserver in ein temporäres Verzeichnis installieren
 > > > > (»make DESTDIR=/... install...«), und dieses dann auf den
 > > > > Client kopieren (per cpdup, cpio, tar, was auch immer).
 > > > 
 > > > also das gefällt mir am besten :-) Meinst Du so was wie:
 > > > 
 > > > build# cpdup -o -j0 /export/i386/ client:/
 > > 
 > > Ja, im Prinzip ...
 > > 
 > > > Ich habe es probiert und es geht (vermutlich Glück), sieht aber wie ein 
 > > > Holzhammer aus. Vermutlich ist es besser, erst den neuen Kernel zu 
 > > > kopieren und danach das Userland zu ersetzen.
 > > 
 > > Ja, ganz so wie oben hätte ich mich's nicht getraut.  :-)
 > > 
 > > Aber wenn das Zielsystem idle ist, kann man wohl tatsäch-
 > > lich Glück haben.  Auch Minor-Updates (8.x --> 8.y) sollten
 > > in der Hinsicht relativ problemlos sein, weil sich in dem
 > > Fall an der ABI normalerweise nichts ändert, d.h. es kommen
 > > keine neuen Syscalls hinzu oder so.
 > > 
 > > Pech kann man bei einem Major-Update haben (7.x --> 8.y),
 > > wenn Binaries vor dem neuen Kernel installiert werden, die
 > > dann versuchen, Syscalls zu verwenden, die der laufende
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bernd Walter | 13 Mar 2011 16:12
Picon

Re: crosscompile FreeBSD i386

On Sun, Mar 13, 2011 at 02:56:48PM +0100, Oliver Fromme wrote:
> Bernd Walter wrote:
>  > Es geht nicht nur um neu gestartete Prozesse.
>  > Man sollte sich auch darüber im klaren sein womit man kopiert,
>  > weil eine Shell, mit der man sich gerade eingelogged hat, um das
>  > kopieren zu starten, oder der Kopierbefehl selber auch crashen kann,
>  > wenn die Binaries überschrieben werden.
> 
> Das ist aus zwei Gründen kein Problem.
> 
> Erstens überschreibt cpdup (um das ging es hier) niemals
> Dateien.  Es kopiert sie zunächst unter einem temporären
> Namen und macht dann ein atomares rename(2).

Das ist gut, aber macht nicht zwingend jedes Tool so.

> Zweitens erlaubt FreeBSD nicht das Öffnen von Dateien zum
> Schreiben, die gerade vom Runtime-Linker geöffnet sind.
> Bei dem Versuch gibt es ein ETXTBSY (»Text file busy«).

Stimmt - jetzt stellt sich mir die Frage wie mir das damals auf
die Füße gefallen ist.
Natürlich ist es klar, dass man so ein halb installiertes System
erhält, was ggfs. auch keine Binaries mehr starten will, aber ich
erinnere mich genau daran, dass die laufenden Prozesse dann plötzlich
alle gestorben sind.
Naja - viel zu lange her, um mich noch daran zu erinnnern.

--

-- 
B.Walter <bernd <at> bwct.de> http://www.bwct.de
(Continue reading)

Permalink | Reply | 3 comments |
headers
Oliver Fromme | 13 Mar 2011 21:13
Picon

Re: crosscompile FreeBSD i386

Bernd Walter wrote:
 > Oliver Fromme wrote:
 > > Zweitens erlaubt FreeBSD nicht das Öffnen von Dateien zum
 > > Schreiben, die gerade vom Runtime-Linker geöffnet sind.
 > > Bei dem Versuch gibt es ein ETXTBSY (»Text file busy«).
 > 
 > Stimmt - jetzt stellt sich mir die Frage wie mir das damals auf
 > die Füße gefallen ist.

Hmm, vielleicht war das ein anderes OS?  Soviel ich weiß,
hat z.B. Solaris nicht diesen Schutz, d.h. dort kann man
ein laufendes Binary überschreiben, was früher oder später
zu einem Coredump führen kann.  Wie Linux sich verhält,
weiß ich nicht, insbesondere wenn auch NFS im Spiel ist.

Vielleicht ist die Installation bei Dir auch aus irgend-
einem anderen Grund abgebrochen.  Wenn das an einer un-
günstigen Stelle passiert, hat man evtl. ein Problem.

Solche Aktionen sollte man natürlich nicht remote auf einem
Rechner machen, zu dem man keinen Consolenzugang hat.  (Ich
erwähne das nur der Vollständigkeit halber für diejenigen,
die hier noch so mitlesen.)

Gruß
   Olli

--

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
(Continue reading)

Permalink | Reply | 2 comments |

Gmane