[DE] wie installation auf usb-stick schneller updaten???

[michaa7]

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?

 

[bluelupo]

Hi michaa7,
nur so eine Idee (ungetestet). Eine Kopie mit "dd" des USB-Sticks machen, dann mounten...

Code: [Select]

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

[michaa7]

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

[melmarker]

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.

[michaa7]

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

[hschn]

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

[michaa7]

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

[melmarker]

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.

[michaa7]

...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? 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,"
/EDIT2

Die entsprechende zeile in der /etc/fstab sieht o aus:

UUID=<xxx>    /                    ext2         defaults,relatime,errors=remount-ro           0    1

Wie sollte die konkret aussehen?

Und 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?

[hschn]

@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

[melmarker]

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

[michaa7]

aber noatime wird doch nicht durch tune2fs sondern durch /etc/fstab?

So sehen die wesentlichen einträge derzeit aus:

Filesystem 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:

Code: [Select]

# tune2fs -O extents,uninit_bg,dir_index /dev/<Gerätedatei>

dann noch fstab etsprechend geändert (ext4, noatime)

[melmarker]

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.

[michaa7]

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?

[melmarker]

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