# Verteilung der Verzeichnisse auf Partitionen optimieren

## dilandau

Für Gentoo System sind im moment 4 GB direkt am anfang von hdb eingesetzt (dort lädt diese platte mit abstand deutlich schneller vergleichen mit ihrem ende). Swap befindet sich auf hda. Hda und hdb sind am selben IDE strang. Welche art von geschwindigkeitsgewinn bringt diese auftielung? Ist paralleler leseschreib-zugriff auf beide platten möglich oder nur zb lesen auf hda während hdb kopf positioniert wird, oder liegt bei ide platten am selben strang der gewinn immer nur darin, daß die köpfe beider platten insgesamt weniger positioniert werden müssen, da daten, die gleichzeitig wichtig sind, in der nähe jeweils eines kopfes liegen? (uaaahh, langer satz)

Jetzt will ich die performance weiter verbessern, indem ich einen teil des root-verzeichnisses, zb var odeer var/tmp von hdb auf eine extra partition auf hda lege. der swapspace wird anscheinend relativ selten gebraucht aber wie ist es wirklich? wäre bei einer auslagerung von zb var von hdb auf hda besser, den swap von hda auf hdb zu verschieben, oder gar auf eine dritte platte? welche vorteile oder besondere eigenschaften täte im vergleich die kooperation mit einer platte am ANDEREN ide strang bieten?

----------

## kollega

hi

ich glaube dein vorhaben in sachen verteilung der verzeichnisse und mountpoints bringt dir nicht wirklich viel... wenn ich deine "ausstattung" ansehe, dann spürst du denk ich davon noch nicht mal einen hauch an performance wenn du vor der kiste sitzt... du kannst zwar deine partitionen auf verschiedene platten legen, aber ich denke wie gesagt dass du nichts spüren wirst... das hat man früher mal gemacht, unter OS/2. da gab es das hpfs. und da hat man die "Systempartition" auf D: gesetzt, weil diese weiter innen auf der kreisrunden platte lag... aber das war ma als man noch auf dem platteninneren eine größere bahngeschwindigkeit(oder doch winkelgeschwindigkeit?!) hatte und dadurch einen schnelleren zugriff... mittlerweile drehen sich die platten auch variabel, so dass du egal, wo der schreib/lesekopf ist immer die gleiche scheibengeschwindigkeit hast...

bei den heutigen zugriffszeiten kannst du vielleicht noch ein wenig mit hdparm spielen oder dir gleich ne SATA-Platte reinbauen... denn egal wo du irgendwelche partitionen legst. das filesystem reorganisiert sich immer wieder selbst...

in diesem Sinne

greeetz tobi

----------

## dilandau

Mißverständnis?

Die zugriffgeschwindigkeit in abhängigkeit zur lage der partition auf einer platte (seagate baracuda 80gb) wurrde mit hdparm gemessen und es ist, daß am anfang mit abstand schneller ist. die rede ist aber von einer verteilugn auf unterschiedliche PLATTEN (hda/hdb), nicht nur  partitionen. Es ist nicht klar, was du mit "reorganisation" meinst).

----------

## kollega

ich glaube das bleibt sich gleich, ob du nun auf hda oder hdb deine partitionen hast. ein unterschied ist es, wenn du sie auf hdc oder hdd hängst, denn dann bist du ja an unterschiedlichen ide-bussen und das kostet performance...

reorganisation damit meine ich, dass das system seine verzeichnisse und daten so umherschiebt auf einer partition wie es für es am günstigsten ist... du kannst nicht explizit auf einen bestimmten block schreiben und dann nach einiger zeit erwarten, dass die daten dann am selben block liegen...

weiß nicht, ob du das schon gelesen hast http://www.zip.com.au/~akpm/linux/ext3/

wenn du überhaupt ext3 hast

greetz

----------

## dilandau

diese features sind mir bekannt. deine ausführung widerspricht stellenweise dem, was die logik gebietet. bitte antowrtet jemand, der voll total sich auskennen tut und das selbe schonmal effektiv gelöst hat.

----------

## kollega

dann probier doch einfach selbst aus, nach dem motto: try and error...

oder les selbst nach!!!! ich weiß ja nicht, welche logiken du hast, aber dass die bahngeschwindigkeit größer wird je kleiner der radius ist, hab leider nicht ich aufgestellt sondern ein Sir Isaac Newton...

vorallem glaub ich bis jetzt noch nicht, dass du es wirklich spürst, wenn du die partitionen nach deiner theorie anlegen willst... oder was bringt es dir, wenn du deinen kernel nicht in 1000,99s sondern in 1000,989s durchkompilierst? am ende bremst dich der stdout am monitor noch aus oder der fall, dass du eine korrupte source hast, bei der das md5 oder digest nicht stimmt... oder lass doch mal den updatedb prozess dazwischen kommen... vielleicht müsstest du ja wirklich wieder zur guten alten batchverarbeitung zurückkehren und roundrobin samt preemptiver verarbeitung komplett vergessen.

in diesem sinne

----------

## dilandau

die performance mit den zwei platten und dem auslagern von var/tmp o.ä. muss jemand anders beantworten, das will ich nicht 'testen'. für sowas gibts erfahrungswerte, da wusste ich mal jemand. schut up, du bist nicht mehr gefragt.

----------

## beejay

 *dilandau wrote:*   

> die performance mit den zwei platten und dem auslagern von var/tmp o.ä. muss jemand anders beantworten, das will ich nicht 'testen'. für sowas gibts erfahrungswerte, da wusste ich mal jemand. schut up, du bist nicht mehr gefragt.

 

Ich kann mir auch nicht vorstellen, dass sich die Performance wirklich erhöht. Allerhöchstens, wenn Mountpoints wirklich vielen Zugriffen auf die schnellere Platte ausgelagert werden. Das ist aber auf Desktop Maschinen in der Regel überflüssig, da hier alle Mountpoints relativ gleich belastet werden. Server dagegen arbeiten viel in /var, Rechenpferde denke ich mehr in /tmp.

Eine Aufteilung würde in Sachen Geschwindigkeit also wirklich nur in sehr speziellen Fällen etwas bringen. Für sowas nimmt man dann aber auch keine solch halbgaren Lösungen, sondern schafft sich gleich ein gescheites Hardware-RAID an.

Im Übrigen finde ich - Verzeihung - Dein Verhalten hier unter aller Sau. Du stellst eine Frage und Dir antwortet jemand. Wenn Du es von vorneherein besser weisst, dann brauchst Du auch nicht zu fragen. Oder suchst Du nur eine Bestätigung für Deinen bereits gefassten Entschluss? Nix für ungut  :Wink: 

----------

## kollega

merci beej für deine unterstützung.

ich muss sagen, dass ich immernoch zum testen stehe, denn nur dadurch kommt man an erfahrungen... ich teste jeden tag irgendwelche solaris-mühlen auf last- und stressverhalten... dann dreht man hier und da an einigen params an tomcat apache usw und probiert erneut... nicht umsonst gibt es firmen, die teure tools dafür verkaufen um solche tests zu ermöglichen! ich bin immernoch der meinung, dass man mit einem 1.6GHz Prozessor keine merkbaren vorteile hat. wie du schon sagtest, gescheite hardware muss her. denn irgendwann bringen die besten flags und andere tuning maßnahmen nix mehr, wenn die hardware am rande ihrer belastungsgrenze steht... ein arbeitskollege von mir, hat sich einen neuen rechner mit irgendwas an die 3GHz oder mehr gekauft und hat alles auf native-scsi, dann wundert er sich wieso der compile-prozess ewig dauerte... nachgelesen und siehe da, sata is einfach um ein vielfaches schneller als scsi. irgendwo setzt auch die physik seine grenzen...

ich bin zwar kein anhänger der freunde zur erhaltung der deutschen sprache, aber das absolute "denglisch" tut ja sogar mir in meinen augen weh.  *Quote:*   

> schut up

 

wahnsinn!

----------

## py-ro

 *Quote:*   

> Hda und hdb sind am selben IDE strang. Welche art von geschwindigkeitsgewinn bringt diese auftielung? Ist paralleler leseschreib-zugriff auf beide platten möglich oder nur zb lesen auf hda während hdb kopf positioniert wird

 

Keinen! Nachdem was ich mal vorjahren in meiner Ausbildung gelernt habe...

IDE ist immernoch ein billig System, wenn ein Gerät an einem Strang angesprochen wird, kann nicht auf ein  anderes Gerät am selben Strang zugegriffen werden, deswegen hat man früher, wenn möglich den Brenner an einen eigenen Strang gehängt.

Das warten auf die Kopfpositionieren muss der Controller leider mitmachen, disconnect( das zugreifen auf ein anderes Gerät während dieser Phase) wird AFAIK nur bei SCSI unterstützt.

MfG

----------

## kollega

[quote="py-ro"][quote]

Das warten auf die Kopfpositionieren muss der Controller leider mitmachen, disconnect( das zugreifen auf ein anderes Gerät während dieser Phase) wird AFAIK nur bei SCSI unterstützt.

/quote]

... oder SATA AFAIK

----------

## py-ro

SATA hab ich vergessen   :Embarassed: 

 *Quote:*   

> sondern schafft sich gleich ein gescheites Hardware-RAID 

 

Softwareraid tuts auch(zumindest bei IDE aus mehrfacher Erfahrung).

Aber swap Partitionen auf RAID wegen Geschwindigkeit legen bringt AFAIK nichts, weil der Linux Kernel diese, wenn mehrere Vorhanden, entsprechend anspricht.

----------

## seth77

Hi

wobei doch bei SATA sowieso nur ein Gerät an einem Controller hängt? PunktZuPunkt-Verbindung  :Smile: 

Gruß Alex

----------

## kollega

bremst ein sw-raid nicht auch wieder aus? 

wo ist denn dann der ganze gedanke der performance???   :Twisted Evil: 

----------

## py-ro

1. sind die meisten, sprich die günstigen, IDE RAID Controller eh zum grössten Teil Software RAIDS(über die Treiber).

2. Optimiert der Hardware RAID die Verteilung nach Erhalt der Schreib/Leseoperation und optimiert den Zugriff, während das Software RAID schon im Kernel einfach andere Schreib/Leseanweisung setzt. Deshalb fällt die Umwandlung im RAID Kontroller Weg(Die erforderlichen Operationen müssen im Kernel eh gemacht werden)

So heben sich beim IDE RAID 0 und 1 die vorteile Gegenseitig auf.

----------

## ralph

Lieber dilandau,

es ist wirklich unerhört, dass Leute es wagen auf deine Frage zu antworten, die dir auch noch begründet erzählen, warum dein Vorhaben Mumpitz ist.

Deswegen jetzt ein Tip vom Profi:

1. Platten öffenen. (Einfach mit einem Schraubenzieher aufhebeln, kann man ja nachher alles mit einem Hammer wieder in Form klopfen)

2. Großzügig Weihwasser über das zu optimierende Laufwerk verteilen. (Da bitte nicht sparsam sein, denn viel hilft ja bekanntlich viel)

3. Anschließend mußt du nur noch die Platten wieder einbauen und natürlich einmal wöchentlich 7 Rosenkränze beten und schon wirst du die Performance deines Systems nicht mehr wiedererkennen.

P.S.: Habe ich natürlich alles ausgiebigst getestet. Dir bleibt also das lästige Nachdenken und Ausprobieren erspart.

Viel Spaß mit deinem neuen System.   :Very Happy: 

----------

## dilandau

py-ro, ich werde dir jeztz nicht die stiefel lecken, denn das kopieren von hda nach hdb IST schneller als zur selben platte. die kopfpositionierungszeit fällt nämlich bei der zwei-platten lösung weg und wenn zwei datenareale gleichzeitig benötigt werden, zb beim kompilieren die exes in bin/laden und die sources, dann liegen die sources auf einer extra paltte genau richtig. das brauche ich jetzt nur noch von einem testsklaven bestätigt und irh anderen raus aus meinem thread denn das was ihr schreibt hat überhaut garnix mit meiner frage zu tun! kscht kscht kscht!  :Very Happy: 

----------

## ruth

hi,

@ ralph:

hihi, recht hast du...

@dilandau:

 *Quote:*   

> 
> 
> bitte antowrtet jemand, der voll total sich auskennen tut 
> 
> 

 

ogott, PISA hat zugeschlagen...

werd erstmal erwachsen, mein freund...

und das da ist ja wohl die höhe:

 *Quote:*   

> 
> 
> schut up, du bist nicht mehr gefragt.
> 
> 

 

wende bitte selbiges statement auf dich selbst an.

wenn du der pubertät entsprungen bist, bist du hier wieder herzlich willkommen...

gruss

rootshell

----------

## py-ro

............................

............................

............................

............................

Autsch was bist du den für einer???!!!

1. Hab ich nie was anderes behauptet, wer denken kann kommt auch drauf warum das so ist wie du sagst....

2. ........(wegen zu guter Erziehung gestrichen)

----------

## dilandau

Ja, PISSA! Ich weis, mein Ding steht schief! Wird mich die Frau dafür bestrafen?? Mwahaha hö bitte bitte jajaja ^-^' rolf

----------

## ruth

hi,

geh zurück in den kindergarten, lern lesen und schreiben; auch gewisse umgangsformen sollte 

dir mal jemand beibringen...

hat dich deine mami nicht mehr lieb???

spass beiseite:

benimm dich oder geh weg !!!

gruss

rootshell

----------

## ian!

dilandau,

ich denke es ist jetzt der geeignete Augenblick sich zu Entschuldigen. Dein Verhalten ist wirklich nicht tragbar. Solltest du nicht daran interessiert sein, dass wir hier nett und freundlich miteinander umgehen und du nicht gewillt bist an diese Umgangsformen zu halten, werden wir leider die Sperrung deines Accounts in Erwägung ziehen müssen.

--ian!

----------

## ralph

Ich kann mich dem von rootshell Gesagten nur anschließen und komme deshalb nicht in die Verlegenheit, mit meinen eigenen Worten sagen zu müssen, was ich von deinem Benehmen halte. So bleibt mir zum Glück ersparrt, meine gute Erziehung für jemanden wie dich vergessen zu müssen.  :Twisted Evil: 

----------

