hallo michael,
ich denke, daß eure i/o tests wenig aussagen.
mit dd lest ihr eine einzige datei seriell aus. das optimiert alle
buffer und tricks.
bei der imageübertragung werden aber viele viele wahhlfreie zugriffe
gleichzeitig auf dieselbe datei durchgeführt. das hebelt den cache
paraktisch aus. zumindest den hw cache auf der platte. etwas helfen kann
es, wenn der plattencache des linux größer ist, als die dateigröße des
images. aber auch hier ist die verwaltung des cache eine blackbox.
ich kann mir vorstellen, daß torrent da etwas eigenes macht, da dies ja
ganz genau auf dieses szenario ausgelegt ist.
ich würde folgendermaßen anfangen (etwas für die herbstferien :-):
neuere ssd besorgen (also eine mit min 450 schreiben und lesen).
das komplette lml system (je nach größe ohne userdateien) auf diese ssd
spiegeln und bootbar machen. wohlgemerkt keine virtualisierung, nur den
lml sewrver.
sich einen neueren client mit 6gb sata krallen (so i5 sollte es schon
sein), schaun, daß der nicht grad ne schund nic drin hat, den mit min
32gb ram ausstatten und dann mal mit diesem als server (an derselben
netz infrastruktur) bei ein paar clients die caches füllen (erst 1 dann
2 dann 3 dann 4, schon steht... ääh nein, das kommt erst..., clients
gleichzeitig. möglichst auch mit torrent) und die rate aufschreiben.
danach den ganzen virtuellen kram aus dem server ausbauen und
stattdessen die ssd einbauen und den server hiermit starten.
dann dasselbe testen wie zuvor.
die beiden messungen sollten dir schonmal sagen, ob du am netz, am
server oder an der virtualisierung weiter suchen solltest...
jonny
_______________________________________________
linuxmuster-user mailing list
linuxmuster-user@lists.linuxmuster.net
https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
