Ich erledige auf meiner Ubuntu 16.04-Workstation eine halbwegs regelmäßige Aufgabe: Sie hat eine zweite Festplatte mit Windows 7 darauf. Im Grunde handelt es sich dabei um eine reine Installation, die ich manchmal hochfahre und Windows Update laufen lasse. Die Idee ist, sie für Spiele zu verwenden, aber, nun ja, es stellt sich heraus, dass ich selten Zeit habe. Ich halte sie trotzdem auf dem neuesten Stand.
Diese halbregelmäßige Aufgabe ist das Klonen der Festplatte, ntfsclone
nachdem ich ein solches Update durchgeführt habe. Betrachten Sie es als „Low-Tech“-Snapshotting, denn leider kann Windows nicht in einem LVM-Volume leben. (Nun, es kann, wenn es virtualisiert wird.) Ich habe ein Skript geschrieben, um dies (und ein paar andere Dinge) zu tun, weil ich faul bin, aber der Befehl, der am meisten Zeit in Anspruch nimmt und das Problem verursacht, ist:
ntfsclone -s -o /home/jorg/Images/$(date +%F).ntfsclone /dev/sdc2
Dabei /dev/sdc2
handelt es sich um die Windows-Partition und /home/jorg/Images/
um ein LVM-Volume auf einem RAID1 bestehend aus /dev/sda
und /dev/sdb
. Alle diese Datenträger sind normale Festplatten, die über SATA verbunden sind.
Das Problem, das dabei entsteht: Wenn ich das mache, wird meine Workstation völlig unbrauchbar. Die Reaktionsfähigkeit ist einfach schrecklich. Sogar das Wechseln und Anmelden bei einer virtuellen Konsole ( Ctrl
- Alt
- F1
) ist unerträglich langsam.
Dies ist nicht nur bei Verwendung der Fall ntfsclone
, und deshalb vermute ich Festplatten-E/A. Wenn ich dd
, ein Tool, das ich häufig verwende, um Leuten mit defekten Festplatten zu helfen, mache, passiert dasselbe. Bei ist es sogar noch schlimmer dd
, weil das häufig über USB läuft. Allerdings habe ich als Test mit dem obigen Setup, das nur SATA verwendet , dd
anstelle von verwendet ntfsclone
, und es ist genauso schlimm. Ja, ich verwende den bs
Parameter in, dd
damit die Pufferung korrekt erfolgt.
Die Sache ist die: Obwohl der Computer in 14.04 langsamer wurde, war er nicht unbenutzbar. Er war nur „etwas langsamer“, aber das Surfen, E-Mailen und Terminalen war immer noch erträglich.
Mittlerweile habe ich auch mit den verschiedenen Disk-Schedulern herumgespielt. Die unterstützten Scheduler sind:
cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
Der Wechsel zu cfq
oder noop
hat nicht geholfen. ( echo cfq > /sys/block/sda/queue/scheduler
).
Einige Informationen zu meiner Maschine:
root@tiger:~# uname -a
Linux tiger 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
root@tiger:~# dmidecode -t baseboard | grep -e Product -e Manufacturer
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: F1A75-V PRO
root@tiger:~# free -mh
total used free shared buff/cache available
Mem: 15G 1,7G 2,9G 154M 11G 13G
Swap: 31G 0B 31G
root@tiger:~# for disk in a b c ; do echo \[ Disk informatoin for \/dev\/sd$disk \] ; hdparm -I /dev/sd$disk | grep -e Model -e Transport ; done
[ Disk informatoin for /dev/sda ]
Model Number: ST1500DL003-9VT16L
Transport: Serial, SATA Rev 3.0
* SMART Command Transport (SCT) feature set
[ Disk informatoin for /dev/sdb ]
Model Number: ST1500DL003-9VT16L
Transport: Serial, SATA Rev 3.0
* SMART Command Transport (SCT) feature set
[ Disk informatoin for /dev/sdc ]
Model Number: WDC WD1002FAEX-00Z3A0
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
* SMART Command Transport (SCT) feature set
Mir ist klar, dass meine /dev/sda
und /dev/sdb
keine Kraftpakete sind, aber unter 14,04 haben sie gut abgeschnitten.
Bemerkt jemand auch eine miserable Leistung bei hohem I/O? Wenn ja, haben Sie eine Problemumgehung gefunden?
Antwort1
DerXanmod-Kernelschien zu helfen. Ich habe 16.04 mit SSD-Boot-Laufwerk und Gnome 3.2 ausgeführt. Ich dachte, der Deadline Scheduler würde es tun, aber das schien nicht viel zu helfen. So habe ich es gemacht: http://www.hecticgeek.com/2016/09/supercharge-ubuntu-16-04-lts-xanmod-kernel/