Dateisystem schnarchlangsam

[hennes]

Hallo,

ich benutze Debian Wheezy auf einem Dell Latitude D830 Laptop und bisher war das Ding auch immer verdammt hastig.
Aber im Verlauf dieses Jahres wurde die Kiste immer langsamer. Ich bin Entwickler und habe viel mit einer Unmenge sehr kleiner Dateien zu tun. Der Startvorgang dauert alleine schon zwei Minuten. Das Kopieren von 13.000 Dateien mit einer Gesamtgröße von lächerlichen 67 MB dauert mit dem Gnome-Nautilus geschlagene 12 Minuten.
Mein Dateisystem ist ext3.

Wo kann ich nachsehen, wo hier die ganze Zeit abbleibt?

Bevor Fragen kommen:

Code: Alles auswählen

hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   3142 MB in  2.00 seconds = 1572.78 MB/sec
 Timing buffered disk reads: 198 MB in  3.02 seconds =  65.56 MB/sec

Viele Grüße
Hennes

[DeletedUserReAsG]

Wo kann ich nachsehen, wo hier die ganze Zeit abbleibt?

iotop wäre mein Einstiegspunkt.

[Saxman]

Nur so als Idee, wenn du sehr viel mit kleinen Dateien zu tun hast, kann es sein, dass dir die Inodes im Dateisystem ausgehen.

Code: Alles auswählen

df -i

gibt Auskunft. Allerdings äußert sich das i.d.R dadurch, dass kein freier Speicher mehr angezeigt wird, obwohl noch x GB frei sein können, nur eben die Inodes ausgegangen sind.

Ansonsten kannst du auch einen anderen scheduler, z.B deadline

Code: Alles auswählen

echo deadline > /sys/block/sda/queue/scheduler

versuchen, ob du dadurch einen besseren Durchsatz auf der Platte bekommst.

Code: Alles auswählen

iotop -pao

kann dir auch einen Hinweis geben, ob noch etwas anderes die Platte in dem Moment auslastet.

[hennes]

iotop meldet dann

Code: Alles auswählen

Total DISK READ:       0.00 B/s | Total DISK WRITE:    1140.11 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND          
  316 be/4 root        0.00 B/s   34.55 K/s  0.00 % 97.69 % [kjournald]
29452 be/4 hennes      0.00 B/s  349.33 K/s  0.00 %  0.24 % nautilus

alles andere ist auf 0.

Code: Alles auswählen

# df -i
Dateisystem             Inodes IBenutzt   IFrei IUse% Eingehängt auf
rootfs                 9142272   823717 8318555   10% /

Mit dem anderen Scheduler komme ich nicht einmal mehr auf 100 kB/s

Hennes

[Saxman]

Du kannst einen Teil deiner Dateien von der Festplatte auslagern und prüfen ob das Problem dann immer noch auftaucht, auch wenn df -i nicht darauf hinweist, dass viele Dateien drauf sind. Einen Versuch ist es wert. Außerdem kannst du einen neueren kernel, z.B. aus den Backports, ausprobieren, wie der sich verhält. Ich würde auch das Dateisystem auf ext4 hochziehen. Die Üblichen Verdächtigen sind in solchen Fällen der Scheduler und das Dateisystem, bzw. dessen journaling, sofern kein Hardwarefehler vorliegt und deine Platte langsam abraucht (smartctl -A /dev/sda). Du kannst auch dafür sorge tragen, dass beim Kopieren die Daten länger im Speicher gehalten werden (commit=300 in der fstab), bevor sie auf die Platte gesynct werden. Allerdings sind dann bei einem Stromausfall die Daten der letzten 5 Minuten weg. Das würde ich jetzt noch so Ad Hoc aus dem Ärmel schütteln.

Du könntest testweise das journaling deaktivieren oder z.B. zu data=writeback ändern. Das ist alles allerdings dann etwas tricky, wenn du nur eine Partition hast und von ihr bootest.

[hennes]

Puh, eine Menge zu tun. Ich fange mal mit dem smartctl an, allerdings habe ich keinen Schimmer, was mit die Zahlen sagen:

Code: Alles auswählen

smartctl -A /dev/sda
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   100   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0007   252   252   025    Pre-fail  Always       -       2062
  4 Start_Stop_Count        0x0032   081   081   000    Old_age   Always       -       197841
  5 Reallocated_Sector_Ct   0x0033   252   252   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   083   083   000    Old_age   Always       -       8741
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       1593
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       6596
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       61
194 Temperature_Celsius     0x0022   103   073   000    Old_age   Always       -       45 (Min/Max 13/55)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       29164 (0, 7)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       5354
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       11859
199 UDMA_CRC_Error_Count    0x0036   252   252   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000a   252   252   000    Old_age   Always       -       0

Gibt es eine Methode, schmerzlos von ext3 auf ext4 umzusteigen?

[Saxman]

Code: Alles auswählen

196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       29164 (0, 7)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       5354
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       11859

Die smartwerte zu interpretieren ist eine Kunst für sich, ich bin da jetzt auch kein Profi. Soweit ich das aber beurteilen kann, hat die Platte zumindest ein paar kaputte Sektoren. Du kannst aber auch noch einen Selbsttest anstoßen (smartctl -t short/long /dev/sda).

Gibt es eine Methode, schmerzlos von ext3 auf ext4 umzusteigen?

Du kannst in der fstab ext3 gegen ext4 wechseln. Wenn du die features von ext4 nutzen willst (optional), reicht ein

Code: Alles auswählen

tune2fs -O extents,uninit_bg,dir_index /dev/sda

Die Features werden aber erst bei neu geschriebenen Dateien genutzt, wenn du das Dateisystem konvertierst und nicht neu anlegst.

Anschließend noch ein

Code: Alles auswählen

fsck -fCVD /dev/sda

Ich würde das alles aber nicht im laufenden Betrieb machen, sondern von einer LiveCD booten, insbesondere für den fsck. Ein Backup deiner Daten solltest du zur Sicherheit auch anlegen.

[hennes]

Ich denke, ich werde erst einmal ein paar DVDs kaufen müssen um meine Platte zu sichern.
Ein paar defekte Sektoren hat wohl sicherlich jede Platte, aber weniger als 100 kB/s ist ja wohl eine Zumutung.
Ich habe mal einen Haufen Projekte á 17.000 Dateien in Archive gepackt, also eine Menge i-nodes entlastet, aber die Geschwindigkeit hat dadurch nicht wirklich zugenommen.
Das kann ich allerdings erst morgen machen, daher für heute erst einmal gute Nacht und Danke für die Tipps.

[Saxman]

Wenn du nicht schon hast, installiere dir den smart-notifier. Dann bekommst du grafisch eine Nachricht, wenn deine Festplatte aussetzen sollte. Festplatten haben eine bestimmte Anzahl an Reserveblöcken, falls Fehler auftreten sollten, d.h erst ab einer bestimmten Schwelle sind Fehler kritisch. Wie hoch diese Schwelle bei dir ist, kann ich aber nicht beurteilen, wie gesagt, bin diesbezüglich auch kein Profi. Vielleicht findet sich ja noch jemand, der das besser interpretieren kann. Ganz auf die leichte Schulter würde ich das aber nicht nehmen.

[NAB]

Das Kopieren von 13.000 Dateien mit einer Gesamtgröße von lächerlichen 67 MB dauert mit dem Gnome-Nautilus geschlagene 12 Minuten.

Gibt es parallel dazu Meldungen im dmesg?

[peschmae]

Wie lange dauert denn das kopieren derselben Dateien auf der Kommandozeile? Eventuell ist ja auch nur Nautilus doof...

MfG Peschmä

[hennes]

Moin und erst einmal einen schönen vierten Advent!

Ich habe als erstes einmal meine fstab derart modifiziert, dass ich den Parameter noatime mit in die Partition aufgenommen habe, da mich persönlich dieser Wert eh nicht interessiert.
Nun scheint alles schon etwas hastiger zu gehen. Mein aktuelles Projekt hat 12.621 Dateien in 67,7 MB.

Code: Alles auswählen

time cp -R Project/XXX/src /var/www/XXX

real	1m17.290s
user	0m0.112s
sys	0m2.116s

iotop meldet parallel dazu Spitzenwerte beim Schreiben um 3 MB/s, kurzzeitig sogar 5 MB/s.
Dmesg liefert keinerlei Angaben und ist seit dem Booten ohne Meldungen.

Dieselbe Aktion über den Nautilus dauert (handgestoppt) 10'25''. Schnaaarrrchhhh.

Nautilus Doof !!

Ne, jetzt mal ernsthaft: Was ist denn hier nun wieder am Kochen?

Viele Grüße
Hennes

[rendegast]

Was ist denn hier nun wieder am Kochen?

Genau das:

196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 29164 (0, 7)
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 5354
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 11859

Saxmans
"Soweit ich das aber beurteilen kann, hat die Platte zumindest ein paar kaputte Sektoren."
ist da in der Dringlichkeit sehr zurückhaltend.
Die Platte ist am Arsch.
Auf der Platte nicht mehr arbeiten resp. mounten.

Erstelle ein Rettungs-Image der Platte, zBsp. gddrescue.
Das Programm müßte ob der schon bekannten Plattenfehler gleich mit passablen Einstellungen benutzt werden, da eine einfache Verwendung sich wohl festfrißt.

Code: Alles auswählen

ddrescue [-R] [-d] --max-retries 1 IN OUT logfile
(wiederholt)
(Doku lesen, '-d' ist ein langsamer Modus, kann helfen, kann aber auch nur verlangsamen)

Alternativmyrescue

Code: Alles auswählen

myrescue [-R] -S -B bitmap.datei IN OUT
(wiederholt)
(Standard ist 1 Retry, Doku lesen)

Aus diesem Image kopiere(!) noch wichtige Nutzdaten. Datei-Kopieren, da die in der Masse auftretenden Fehler möglicherweise auch die Dateisystemstruktur betreffen.
Vergleiche diese Kopien mit Kopien, die noch von von der beschädigten Platte erhalten werden können.



Nach www gab es das Gerät wohl mit 120GB Platte,
sowas per USB2 zu sichern ~ 2h, an einem Plattenport aber nur ~ 1/2h.
Daher die fehlerhafte Platte besser zusammen mit neuen Platten einhängen in einen Desktop-Rechner.

[Lord_Carlos]

Welche kernel version benutzt du?

War das nicht immer schon so das der Linux kernel mit vielen IO operationen nicht klar kommt: https://bugzilla.kernel.org/show_bug.cgi?id=12309

[NAB]

Was ist denn hier nun wieder am Kochen?

Genau das:

196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 29164 (0, 7)
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 5354
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 11859

Das hatte ich auch vermutet ... aber hätten dann nicht Fehler im dmesg auftauchen müssen?

[hennes]

Wie gesagt, meldet dmesg keinerlei Fehler. Was mich eher wundert ist ja auch diese Diskrepanz zwischen Kommandozeile 1'17'' und Nautilus 10'25''. Weshalb ist der Nautilus soviel langsamer?

Plattenfehler kann ich natürlich nicht ausschließen, allerdings zeigt das Log auch Wochen zurück keine Fehler. Würden die überhaupt ins Log protokolliert??

Zur Frage nach meiner Kernelversion:

Code: Alles auswählen

uname -a
Linux debian01 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u2 x86_64 GNU/Linux

Ein ganz normales Debian Wheezy.

Hennes

[Saxman]

[...]Plattenfehler kann ich natürlich nicht ausschließen,[...]

Die Platte hat definitiv Fehler, das steht gar nicht mehr zur Debatte. Fraglich war nur, ob die Fehler so reichhaltig sind, dass die Platte als kaputt bezeichnet werden kann. rendegast bejaht das und ich neige dazu Ihm zu glauben. Also, für dich heißt das, am besten Platte sichern und eine neue kaufen, mehr kannst du in dem Fall leider nicht mehr machen. An den Symptomen herumdoktern wird dir nicht helfen, im Zweifel verlierst du nur deine Daten.

[hennes]

Alles klar. Dann bleibt nur noch die Frage: Sollte ich gleich eine SSD kaufen oder lieber wieder eine normale?

[Saxman]

Alles klar. Dann bleibt nur noch die Frage: Sollte ich gleich eine SSD kaufen oder lieber wieder eine normale?

Performancetechnisch stellt sich die Frage nicht.

SSD

Code: Alles auswählen

# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   4444 MB in  2.00 seconds = 2223.55 MB/sec
 Timing buffered disk reads: 702 MB in  3.00 seconds = 233.78 MB/sec

HDD

Code: Alles auswählen

# hdparm -tT /dev/sdc

/dev/sdc:
 Timing cached reads:   4216 MB in  2.00 seconds = 2109.27 MB/sec
 Timing buffered disk reads: 460 MB in  3.00 seconds = 153.28 MB/sec

Die SSD habe ich schon seit einigen Jahren im Betrieb, die HDD ist neuer.. Die neueren SSDs sind sicher noch schneller. Der einzige Grund für eine Festplatte wäre in meinen Augen, wenn du sehr viel Platz benötigst und keine zweite Platte hast. Ansonsten ganz klar, SSD.

[DeletedUserReAsG]

Performancetechnisch stellt sich die Frage nicht.

Gerade bei vielen kleinen Dateien, von denen hier ja anfangs die Rede war, macht ein SSD (Neutrum) schon einiges mehr her als eine Platte, deren Köpfe sich für jede Datei neu positionieren müssen.

[NAB]

Also, für dich heißt das, am besten Platte sichern und eine neue kaufen, mehr kannst du in dem Fall leider nicht mehr machen. An den Symptomen herumdoktern wird dir nicht helfen, im Zweifel verlierst du nur deine Daten.

"Kaputte Platte" erklärt aber nicht, warum das Symptom mit cp auf der Kommandozeile nicht auftritt. Das kann durchaus ne Macke in Nautilus sein.

(Bei der Platte hätte ich trotzdem Vertrauensprobleme)

[Saxman]

Also, für dich heißt das, am besten Platte sichern und eine neue kaufen, mehr kannst du in dem Fall leider nicht mehr machen. An den Symptomen herumdoktern wird dir nicht helfen, im Zweifel verlierst du nur deine Daten.

"Kaputte Platte" erklärt aber nicht, warum das Symptom mit cp auf der Kommandozeile nicht auftritt. Das kann durchaus ne Macke in Nautilus sein.

Mag durchaus sein, allerdings sind max. 5 MB/s bei einem Kopiervorgang in der Konsole auch kein Rekordwert. Fehler äußern sich bei kaputten Platten unterschiedlich. Mag sein, dass der grafische overhead von Natilus das noch verstärkt.

[pferdefreund]

insbesondere, wenn Nautilus so schlau sein will, viele Dateien parallel zu kopieren - da ist dann der Zugriffsarm der Platte nur noch am Schwingen. Mag sein, dass er dadurch aus der "spur" kommt und sich öfters neu justieren muss - an den Service-Tracks, so es die heute noch gibt.