Ich habe vor wochen/monaten eine ganz normale installtion auf einen usb-sick gemacht, diese bereits nach dem install zeitaufwendig aktualisiert. Bei der heutigen aktualisierung (die ich vor allem zwecks DMO freier aktueller testumgebung benötige) bin ich fast vom stuhl gefallen: 5 Stunden alleine für das entpacken von ca. 450MB packeten (*ohne* download und *ohne* eigentlichen install).
Ich habe meine archivpartition des regulären installs an die entsprechende stelle der gebooteten usb-installation gemountet (um mir den d/l zu sparen).
Habe ich damit das d-u noch mehr ausgebremst?
Wie stele ich fest ob der usb-host, an dem der stick hängt, usb1 oder 2 ist?
Sind 5 Stunden für 450MB entpacken normal?
Hi michaa7,
nur so eine Idee (ungetestet). Eine Kopie mit "dd" des USB-Sticks machen, dann mounten...
# mount -o loop Stick_abbild.dd /media/usbstick
Danach via chroot in das installierte System wechseln und updaten. Das müsste sehr viel schneller gehen, da du nicht wirklich auf den USB-Stick bist.
Wenn alles abgeschlossen ist via "dd" das Abbild wieder auf den Stick kopieren.
Zitat von: bluelupo in 2014/07/27, 21:06:07
...da du nicht wirklich auf den USB-Stick bist.
...
Dabei bin ich aber doch abhängig von der größe des RAM? Hier ein einziges GB. Falls ich damit recht habe, wird das so nichts, denn während des d-u_s brauchst du ja den ganzen platz der neuen packete zunächst zusätzlich. Mit all den paketen seit Dezember (letztes i386 ISO). Das war der grund weshalb ich die USB-stick installation geupdatet habe und nicht einfach ein ISO.
Stimmt meine überlegung?
Jetzt ist das d-u ja erstmal (wieder) erledigt, aber das war eine strafarbeit ...
Es gibt da was, was funktionieren könnte - eine ganz normale Installation auf USB-Stick. Der müsste dazu wahrscheinlich gekauft werden, Preis nicht so entscheidend, Geschwindigkeit schon - Und den bitte in USB3 -nächstes Problem, das setzt auf mindestens einem Rechner USB 3 voraus - und dann ab dafür :)
Noch einen zu Geschwindigkeiten und Belastungen den Sticks - Ich verwende auf meinen Stöckchen ein kastriertes ext4 ohne Journal, das lässt das Teil weniger altern - ist zwar nicht ganz so sicher, aber das Risiko kann man eingehen, wenn man auch mal ohne Bedenken ext2 benutzt hat - das ist dann ein ext2 auf Steroiden.
Zitat von: melmarker in 2014/07/27, 23:23:30...Und den bitte in USB3 -nächstes Problem, das setzt auf mindestens einem Rechner USB 3 voraus...
Klar wäre das ne lösung, aber erst für den nächsten, derzeit nicht absehbaren rechner, nicht für mein gegenwärtiges problem.
Mal folgender lösungsansatz mit der bitte um bewertung:
d-u im chroot (das geht natürlich auch nicht schneller, aber das ginge (?) doch nebenher, oder?). Ich habe bislang drei-, viermal mit chroot gearbeitet. Kann man in einem VT eine chrootumgebung aufbauen, in den man den usb-stick einhängt und das d-u quasi nebenbei (ggf. mitverändertem nice) laufen lassen?
Nur eine kurze Anmerkung:
auch bei usb2 Anschluß rentiert sich ein usb3 Stick.
Es ist schon ein Unterschied ob die Daten mit voller oder nur halber Geschwindikgeit übertragen werden.
Grüße
hschn
Zitat von: hschn in 2014/08/14, 16:14:26
..
Es ist schon ein Unterschied ob die Daten mit voller oder nur halber Geschwindikgeit übertragen werden. ...
Das ist soweit klar ;-) .
Du sagst also ein usb2 stick nutz immer nur halbe usb2 geschwindigkeit? Oder woher rührt die geschindigkeitszunahme eines usb3 sticks an einem usb2 port?
michaa7: Und das Mounten könnte auch eine entscheidende Rolle spielen - journaled filesystems sind ne feine Sache, aber auf USB2 möchte man die nicht unbedingt haben. DAHER: Partitionen mit ext4.journal abschalten, data=writeback, noatime - und schon sollte das ein wenig schneller rennen. Ich würde mal so die doppelte bis dreifache Geschwindigkeit vermuten. Und wenn man jetzt noch wenigstens einige wenige Teile des Filesystems in das spärlich vorhandene Ram packt, bringt das auch noch was. Ziel ist es möglichst wenig Schreibzugriffe auf dem Stick zu haben - die sind halt schweinelangsam.
Zitat von: melmarker in 2014/08/14, 16:50:36
...ext4.journal abschalten, data=writeback, noatime -
Das wurde als ext2 installiert. Vielleicht liegt da der hund begraben. Kann ich das nachträglich in ext4 konvertieren? Vielleicht sogar dadurch das ich es einfach als solches mounte? Reicht dazu ein entsprechender eintrag in der /etc/fstab? Und wie schalte ich das journal aus. Dazu darf die entsprechend partition ja nicht gemountet sein. Wie kann ich dann darauf zugreifen?
EDIT:
So konvertieren? (http://www.ghacks.net/2010/08/11/convert-ext23-to-ext4/) Wobei ich "has_journal" durch "^has_journal" ersetze?
/EDIT:
EDIT2:
Oder so "Eigentlich brauchst Du nur die jeweils fehlenden features mit 'tune2fs -O [^]feature[,....]' zu (de)aktivieren," (https://debianforum.de/forum/viewtopic.php?p=845459#p845459)
/EDIT2
Die entsprechende zeile in der /etc/fstab sieht o aus:
ZitatUUID=<xxx> / ext2 defaults,relatime,errors=remount-ro 0 1
Wie sollte die konkret aussehen?
ZitatUnd wenn man jetzt noch wenigstens einige wenige Teile des Filesystems in das spärlich vorhandene Ram packt, bringt das auch noch was.
Was und vor allem wie?
@michaa7
Halbe Übertragungsgeschwindigkeit ist ein Durchschnittswert, hängt vom Stickhersteller ab.
Ich hatte schon sticks die nur 10 MByte/s schafften, die meisten 20-25 MByte/s.
Die Usb3 Sticks schaffen ca 40-45 MByte/s, auch Billigsticks.
Grüße
hschn
@michaa7 - abschalten mit ^has_jounal ist glaub ich richtig, noatime ist auch wichtig - data=writeback, commit=30, barrier=0 sollten wohl nur beim Schreiben der Journals wirken und müssten ohne Journal wirkungslos sein.
aber noatime wird doch nicht durch tune2fs sondern durch /etc/fstab?
So sehen die wesentlichen einträge derzeit aus:
ZitatFilesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Also habe ich ja kein journal.
Die kernfrage ist ja: Der stick soll ja im rahmen des möglichen performanter werden. Journal habe ich ja keines, noatime setze ich über /etc/fstab. Muss/sollte ich dort auch ext4 angeben? Welche veränderung veranlaßt denn den kernel die partition mit einem anderen treiber anzusprechen? Allein noatime kann das ja wohl nicht bewirken. Ich meine wenn der stick durch die verwendung von ext4 irgendwie schneller werden soll, dann muß das doch auch irgendwie am entsprechend anderen kerneltreiber liegen.
Edit:
Ich habe es jetzt -ohne journal- nach dieser anleitung
Quelle:http://wiki.ubuntuusers.de/Upgrade_auf_ext4
nachgerüstet:
# tune2fs -O extents,uninit_bg,dir_index /dev/<Gerätedatei> dann noch fstab etsprechend geändert (ext4, noatime)
ext4 ohne journal ist ein wenig schneller als ext2 - hab ich zwar nicht gemessen, aber gelesen. Und ein eventuell notwendiger Filesystem-Check geht im Gegensatz zu ext2 rasant schnell, deshalb bin ich bei Sticks auf ext4 in kastriert gewechselt. Und Du hast recht, noatime wird in der fstab gesetzt.
Zitat von: melmarker in 2014/08/14, 22:38:46
ext4 ohne journal ist ein wenig schneller als ext2 - hab ich zwar nicht gemessen, aber gelesen.
Ich habe eine test gelesen bei dem der gutste eine dreifache geschindigkeit hatte, mit dd.
Ich kann das zumindest was ein d-u betrifft nicht bestätigen, nichtmal ein gefühlter zuwachs. Zwischendurch dachte ich schon da hätte sich was aufgehangen, denn beim entpacken der kernel headers ging es für ca 7-10 M-I-N-U-T-E-N nicht weiter, uuuaagrrrrrrrrrhhhhhhhhhhh
Daher nochmals zu meiner obigen frage: d-u des sticks in chroot im VT nebenher, möglich? Wenn ja, kann man mit dem rechner parallel arbeiten?
aua - das wird mit der "Möhre" nich so einfach, eher nein. Nur mal ne richtig doofe Idee: wenn Du den Stick in eine VM auf einem etwas besser ausgestatteten Rechner klemmst und der VM nur einen Professor zuweist ..
Dann sollte die VM auf jeden Fall nicht den kompletten I/O dicht machen - Wenn ich weiter drüber nachdenke, sollte das auch ohne VM an einem etwas performanteren System möglich sein - so in einer Chroot. Wenn Du den Spass des Updatens auf einem laufenden System machst, schießt Du Dir fürchterlich ins Knie. Das hat Gründe: Die I/O-Leistung des Sticks ist - äh - recht begrenzt, Du hantierst da bei den dev-Paketen mit richtig viel kleinen Dateien, die alle einen separaten Schreibvorgang auslösen und damit den theoretisch möglichen i/O total dicht machen. Damit bleibt dann leider auch nichts mehr für das laufende System über - catch 22
Nicht dass ich behaupten will ich *wüßte* das besser ;-) , bei leibe nicht. Nur ist mir aufgefallen, dass die CPU-last *und* die RAM-auslastung beim d-u des stickes überhaut keine rolle spielen, selbst auf meiner möre nicht, (habe, als es nicht weiterging, in einer zweiten konsole htop laufen lassen). Während des entpackens war die CPU auslastung kontinuierlich zwischen 5-10%, der RAM verbrauch (used+buffer, ohne cache) bei 20-25%, wesentliche komponenten des systems also im halbschlaf. Das deute ich (bei zugegeben eingeschränkter deutungskompetenz) so, dass vor allem das schreiben beim auspacken einen flaschenhals darstellt (Ob demgegenüber der Bus überhaupt eine rolle spielt und wie man die auslastung auf dem USBus sehen könnte wäre allerdings schon interessant!). Wenn ich damit recht habe würde eine bessere CPU und mehr RAM relativ wenig bringen. I/O, liese sich das irgendwie darstellen wie stark die queues oder buffer ausgelastet sind.
Eigentlich ist das alles nebensächlich, aber jetzt würde es mich schon interessieren, ob und wo hier der flaschenhals tatsächlich zu finden wäre.
Nachforschungen im netz ergaben ca. 6MB/S schreiben für den stick.
Der Flaschenhals ist der I/O - ganz klar. Nur wenn Du das Ding nebenbei auf einem unabhängigen System aktualisierts, wird die Gesamtausstattung dieses Systems nich doll belastet - und Du aktualisierst ein System, von dem Du nicht auch nicht noch arbeitest - hmm - eventuell ist das auch auf der "Möhre" machbar. Sorry, wenn ich jetzt was nicht richtig mitbekommen habe - aber das Teil, mit dem aktualisiert wird, sollte nicht von Stick laufen, das wäre kontraproduktiv. Glaub ich zumindest.