Re: geom_*, atacontrol oder Hardware?

On Thu, Nov 18, 2004 at 01:13:13PM +1100, Peter Ross wrote:
> Bernd Walter wrote:
> > On Tue, Nov 16, 2004 at 11:01:37AM +0100, Daniel Graupner wrote:
> >> Bernd Walter schrieb:
> >> >Meine Erfahrungen mit gvinum sind enttäuschend gewesen
> >> Inwiefern enttäuschend. Wegen fehlender Funktionalität, oder wegen
> >> instabilitäten?
> >
> > Instabilitäten - ich konnte auf meinem Testsystem einer alpha mit einem
> > 4 Platten concat nicht mal die Konfiguration einlesen lassen. Das ist
> > meines Wissen nach inzwischen gefixed, aber es braucht eine gewisse
> > Zeit bis ich dem ganzen wirklich vertrauen kann.
>
> War das Problem plattformunabhaengig?

Ich denke schon, da jemand anders auf der -current Liste mit einem i386
System das gleiche gemelded hat - der hat sich damals auch darum
gekümmert, dass das debugged wird.

> Ich selbst benutze FreeBSD nur auf i386, daher habe ich keine Erfahrungen
> mit anderen Plattformen. Beim Durchlesen von TODO-und Bug-Listen habe ich
> aber immer mal wieder den Eindruck, dass es mit Nicht-i386 mehr Probleme
> gibt. Wahrscheinlich auch, weil es nur einme Handvoll Anwender und
> Entwickler gibt..

Ja sicher - das hat mehrere Gründe.
An erster Stelle schon mal die Tatsache, dass Pointer und long 64 bit
sind, was Software die über deren Größe Spekuliert schnell aus dem Tritt
bringt.
Dann kommt noch das Alignment, was auf i386 »nur« der Performance
schaded und die meisten anderen CPUs gleich um die Ohren hauen.
Dann kommt noch die Tatsache hinzu, dass die meisten anderen Platt-
formen in der SMP Technik wesentlich agressiver ausgelegt sind und
es so schnell zu Cache Inkonstenzen kommen kann als auf x86 Systemen.
Im großen und ganzen also vorwiegend Probleme, die auch auf x86
auftreten, aber seltener bemerkt werden.
Abgesehen davon sind 32bit Systeme für einige Anwedungen schon lange
nicht mehr geeignet.

> So wuerde Dein Problem sozusagen FreeBSD/i386 gvinum (und so die
> Hardwareplattform, auf der bestimmt 90+ % aller FreeBSD-Systeme laufen)
> unverdient in schlechten Ruf bringen.

Wenn eine Software Architekturabhängigkeiten hat, dann wäre das
verdient.
Wenn du auf 32bit Maschinen RAID brauchst, dann auf 64bit Maschinen
erst recht.
Das ist genau die Einstellung die viele alpha Entwickler immer wieder
frunstriert und wohl auch vertrieben hat.
Es hat etliche Fälle gegeben wo die alpha Lauffähigkeit nur dadurch
gelitten hat, dass andere ganz schnell Features einbauen mussten, die
offensichtlich nur auf i386 laufen konnten.
Ein großteil was alpha Entwickler tun ist den anderen hinterher zu
räumen und das macht nur solange Spaß wie ein Ende abzusehen ist.

> Es ist ja schon nett, dass es jenseits von i386 noch was anderes gibt, was
> unter FreeBSD laeuft, und bestimmt hilft es auch bei dem nunanstehenden
> Portieren auf die 64-bittigen Nachfolger, aber so richtig begeistert mich
> der Support anderer Architekturen _als Tier-1-Plattform_ nicht.. Gibt es
> dafuer nicht NetBSD?

Wenn du so argumentierst - auch für i386 gibt es NetBSD.
Warum nimmst du dann FreeBSD für i386 Systeme?
Vermutlich aus den gleichen Gründen ist FreeBSD auch jenseits von
i386 meine Wahl.
Die Zukunft ist 64bit - mit welcher Architektur auch immer.
Kein Tier-1 ist nicht so wirklich tragisch, da derzeit ein Großteil
der Leute mit solchen Maschinen in der Lage sind Probleme zu debuggen
und sobald sich das ändert ist das Interesse an Tier-1 auch groß genug.
Im x86 Lager hingegen sind zwar zahlenmässig mehr Leute in der Lage
zu debuggen, aber denoch können es die wenigsten x86 User.

> Ich administriere nun seit 10 Jahren Sun-Kisten und -Clones, so richtig
> habe ich noch nicht einmal einen ernsthaften Bedarf an etwas anderem als
> Solaris gesehen. Sicher, es hat hier und da mal seine Macken und
> Schwachstellen - aber das kann man sicher von jedem System behaupten.
> Irgendwie sehe ich nicht wirklich Bedarf an SPARC-*BSD, es ist in meinen
> Augen eher Spielerei.

Mein Paradefall ist ein bind-9 auf einer E250 mit 2x 250MHz UltraSparc-II
CPUs unter Solaris.
Nachdem ich die Kiste durch eine SS10 mit 1x 40MHz SuperSparc ersetzt
habe war die Performance deutlich schneller.
Der Fall spiegelt sicherlich nicht den Normalfall wieder, aber denoch
so passiert.

Mal davon abgesehen, hast du unter Solaris keine Ports zur Verfügung
hast und bist bei einem Kernel Panic auf Sun angewiesen.
Oder hast du schon mal einen buildworld von Solaris gesehen?
OK - es gibt seit längeren Solaris Sourcen, aber CVS Zugriff wo man
Änderungen auch nachvollziehen kann?

Es gibt schlichtweg Anwendungen für die man mit einem x86 nicht weit
kommt und auch dann möchte ich auf die Vorzüge von FreeBSD oder NetBSD
nicht verzichten müssen.
Wie eng die 4G Addressraum bereits sind kannst du schon seit Jahren auf
der -current und auch -stable Liste nachverfolgen wenn es ums Thema
kmem oder Addressraum im allgemeinen geht.
Bereits heute gibt es haufenweise Kompromisse und Einshränkungen
deswegen.
Beispiel:
Ein einfacher TCP connect braucht heutzutage aleine 96kByte für den
Buffer und größere Buffer sind bereits wünschenswert.
Mit 1G kmem (4G minus 3G für Userland) ist breits bei 10000 TCP
Verbindungen Schluß - von anderen kmem Nutzern mal abgesehen.
Derzeit bleibt einem auf Maschinen mit vielen gleichzeitigen Connects
nichts anderes übrig als die Socketbuffer zu lasten der ereichbaren
Spitzenbandbreite zu verkleinern.
Anderes Beispiel:
Simples mmap einer einzigen DVD und der Addressraum ist bereits zu
klein.
Derzeit muss man auf die Vorzüge von mmap verzichten und kleine
Häpchen mappen, oder anders zugreifen.
Nächstes Beispiel Grafikverarbeitung:
gimp macht eigene swap Files, weil es schlichtweg über den eigenen
Addressraum für große mehrlagige Bilder niemals genügend Speicher
bekommen kann - ein riesiger Overhead nur weil es der Kernel
mangels tauglicher CPU nicht besser kann.
Leider scheinen die Gimp authoren zu glauben, dass es keine 64bit
CPUs gibt, aber das ist ein anderes Thema.

> Am ehesten kann ich mir noch vorstellen, dass es fuer eine Firma
> interessant sein kann, die z.B. mit vorhandenem Prozessor einen NAS-Server
> oder irgendetwas ganz anderes hinstellen will, und als OS *BSD nimmt
> (sicher auch aus Lizenzgruenden). Dafuer wuerden die
> "Mainstream-Unixserver-Portierungen" eher Referenz und Spielwiese fuer
> Portierungen sein. Ist das den Aufwand wert?

Es kommt auf den Anwendungsfall an.

> Mein ganz persoenlicher Blickwinkel dazu (vielleicht durch einen zu
> schmalen Sehschlitz;-)

Mache einfach mal selber deine Vergleiche.

> P.S. Nichts gegen den Spieltrieb;-)

Das hat nichts mit Spieltrieb zu tun.
i386 ist ein Auslaufmodell für immer mehr Anwendungen und wenn FreeBSD
es nicht auch sein will darf es nicht darauf hängen bleiben.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message