# Dauerhafte Festplattenzugriffe

## mknjc

Ich nutze Gentoo auf vielen Computern und alle zeigen das selbe Verhalten, es werden (schreibende) Festplattenzugriffe angestoßen obwohl es garnichts zu schreiben gibt.

Da es mich an meinem Server am meisten gestört hat hab ich das etwas näher untersucht:

Ich hab so viele Programme wie möglich geschlossen. Ausgabe von ps ax:

```
Ragnarok-Server ~ # ps ax

  PID TTY      STAT   TIME COMMAND

    1 ?        Ss     0:22 init [3]         

    2 ?        S      0:00 [kthreadd]

    3 ?        S      0:20 [ksoftirqd/0]

    6 ?        S      0:00 [migration/0]

    7 ?        S      0:00 [migration/1]

    9 ?        S      0:08 [ksoftirqd/1]

   11 ?        S      0:00 [migration/2]

   13 ?        S      0:11 [ksoftirqd/2]

   14 ?        S      0:00 [migration/3]

   15 ?        S      0:24 [kworker/3:0]

   16 ?        S      0:09 [ksoftirqd/3]

   17 ?        S<     0:00 [cpuset]

   18 ?        S<     0:00 [khelper]

   22 ?        S<     0:00 [netns]

  166 ?        S      0:05 [sync_supers]

  168 ?        S      0:00 [bdi-default]

  170 ?        S<     0:00 [kblockd]

  172 ?        S<     0:00 [kacpid]

  173 ?        S<     0:00 [kacpi_notify]

  174 ?        S<     0:00 [kacpi_hotplug]

  339 ?        S<     0:00 [ata_sff]

  346 ?        S      0:00 [khubd]

  353 ?        S<     0:00 [md]

  359 ?        S      0:25 [kworker/2:1]

  455 ?        S<     0:00 [kondemand]

  504 ?        S      2:43 [kswapd0]

  505 ?        SN     0:00 [ksmd]

  614 ?        SN     3:40 [khugepaged]

  616 ?        S      0:00 [fsnotify_mark]

  625 ?        S<     0:00 [aio]

  656 ?        S<     0:00 [xfs_mru_cache]

  659 ?        S<     0:00 [xfslogd]

  660 ?        S<     0:00 [xfsdatad]

  661 ?        S<     0:00 [xfsconvertd]

  663 ?        S<     0:00 [crypto]

  670 ?        S<     0:00 [pencrypt]

  672 ?        S<     0:00 [pdecrypt]

  761 ?        S      0:00 [scsi_eh_0]

  766 ?        S      0:00 [scsi_eh_1]

  769 ?        S      0:00 [scsi_eh_2]

  772 ?        S      0:00 [scsi_eh_3]

  775 ?        S      0:00 [scsi_eh_4]

  778 ?        S      0:00 [scsi_eh_5]

  901 ?        S      0:00 [scsi_eh_6]

  902 ?        S      0:56 [usb-storage]

 1406 ?        S      0:00 [scsi_eh_7]

 1407 ?        S      0:00 [usb-storage]

 1527 ?        S      0:00 [jbd2/sdd1-8]

 1528 ?        S<     0:00 [ext4-dio-unwrit]

 1934 ?        S      9:06 [md127_raid5]

 2050 ?        S      0:31 [xfsbufd/md127]

 2052 ?        S      0:11 [xfssyncd/md127]

 2053 ?        S      0:06 [xfsaild/md127]

 2545 ?        Ss     0:00 /usr/sbin/sshd

 3406 ?        Ss     0:00 sshd: root@pts/1 

 3412 pts/1    Ss     0:00 -bash

 7976 ?        S      0:02 [kworker/1:1]

 7983 ?        SN     0:00 /sbin/udevd --daemon

 7984 ?        SN     0:00 /sbin/udevd --daemon

11494 ?        SNs    0:00 /sbin/udevd --daemon

11802 ?        S      0:18 [kworker/0:0]

11803 ?        S      0:50 [kworker/0:2]

12323 ?        S<     0:00 [loop1]

13275 ?        S      0:08 [kworker/2:2]

13278 ?        S      0:07 [kworker/3:2]

17467 tty1     Ss+    0:00 /sbin/agetty 38400 tty1 linux

18074 ?        S<     0:00 [loop0]

18277 pts/1    R+     0:00 ps ax

18482 ?        S      0:12 [kworker/1:2]

18500 ?        S<     0:00 [loop2]

32686 ?        S      0:00 [kworker/u:1]

32690 ?        S      0:00 [kworker/u:2]

```

Man sieht das sich zwischen den Kernelthreads nur noch udevd, init, ein atty und meine ssh Verbindung verstecken.

Trotzdem bleiben die Zugriffe (Die Festplattenlampe blinkt).

Da iotop nichts anzeigte installierte ich die laptop-mode-tool und führte den Profiler aus:

```
Ragnarok-Server ~ # lm-profiler 

Profiling run started.

Write accesses at 3/600 in lm-profiler run: md127_raid5                     

Write accesses at 10/600 in lm-profiler run: md127_raid5                    

Write accesses at 11/600 in lm-profiler run: md127_raid5                    

Write accesses at 15/600 in lm-profiler run: md127_raid5                    

Write accesses at 17/600 in lm-profiler run: md127_raid5                    

Write accesses at 30/600 in lm-profiler run: md127_raid5                    

Write accesses at 43/600 in lm-profiler run: md127_raid5                    

Write accesses at 56/600 in lm-profiler run: md127_raid5                    

Write accesses at 57/600 in lm-profiler run: md127_raid5                    

Write accesses at 70/600 in lm-profiler run: md127_raid5                    

Write accesses at 83/600 in lm-profiler run: md127_raid5                    

Write accesses at 84/600 in lm-profiler run: md127_raid5                    

Write accesses at 97/600 in lm-profiler run: md127_raid5                    

Write accesses at 110/600 in lm-profiler run: md127_raid5                   

Write accesses at 111/600 in lm-profiler run: md127_raid5                   

Write accesses at 124/600 in lm-profiler run: md127_raid5                   

Write accesses at 137/600 in lm-profiler run: md127_raid5                   

Write accesses at 138/600 in lm-profiler run: md127_raid5                   

Write accesses at 151/600 in lm-profiler run: md127_raid5                   

Write accesses at 164/600 in lm-profiler run: md127_raid5                   

Write accesses at 178/600 in lm-profiler run: md127_raid5                   

Write accesses at 191/600 in lm-profiler run: md127_raid5                   

Write accesses at 205/600 in lm-profiler run: md127_raid5                   

Write accesses at 218/600 in lm-profiler run: md127_raid5                   

Write accesses at 232/600 in lm-profiler run: md127_raid5                   

Write accesses at 245/600 in lm-profiler run: md127_raid5                   

Write accesses at 259/600 in lm-profiler run: md127_raid5                   

Write accesses at 272/600 in lm-profiler run: md127_raid5                   

Write accesses at 286/600 in lm-profiler run: md127_raid5                   

Write accesses at 299/600 in lm-profiler run: md127_raid5                   

Write accesses at 312/600 in lm-profiler run: md127_raid5                   

Write accesses at 313/600 in lm-profiler run: md127_raid5                   

Write accesses at 326/600 in lm-profiler run: md127_raid5                   

Write accesses at 339/600 in lm-profiler run: md127_raid5                   

Write accesses at 340/600 in lm-profiler run: md127_raid5                   

Write accesses at 353/600 in lm-profiler run: md127_raid5                   

Write accesses at 366/600 in lm-profiler run: md127_raid5                   

Write accesses at 380/600 in lm-profiler run: md127_raid5                   

Write accesses at 393/600 in lm-profiler run: md127_raid5                   

Write accesses at 407/600 in lm-profiler run: md127_raid5                   

Write accesses at 420/600 in lm-profiler run: md127_raid5                   

Write accesses at 434/600 in lm-profiler run: md127_raid5                   

Write accesses at 447/600 in lm-profiler run: md127_raid5                   

Write accesses at 461/600 in lm-profiler run: md127_raid5                   

Write accesses at 474/600 in lm-profiler run: md127_raid5                   

Write accesses at 487/600 in lm-profiler run: md127_raid5                   

Write accesses at 488/600 in lm-profiler run: md127_raid5                   

Write accesses at 501/600 in lm-profiler run: md127_raid5                   

Write accesses at 514/600 in lm-profiler run: md127_raid5                   

Write accesses at 528/600 in lm-profiler run: md127_raid5                   

Write accesses at 541/600 in lm-profiler run: md127_raid5                   

Write accesses at 555/600 in lm-profiler run: md127_raid5                   

Write accesses at 568/600 in lm-profiler run: md127_raid5                   

Write accesses at 582/600 in lm-profiler run: md127_raid5                   

Write accesses at 595/600 in lm-profiler run: md127_raid5                   

Write frequency :                                   

     55 md127_raid5

Read frequency : 

Profiling run completed.
```

Das Raid Array sieht so aus:

```
Ragnarok-Server ~ # mount | grep md127

/dev/md127 on /mnt/old type xfs (rw,nobarrier)

Ragnarok-Server ~ # cat /proc/mdstat 

Personalities : [raid6] [raid5] [raid4] 

md127 : active raid5 sdb2[4] sda2[5] sdc2[3]

      2920584448 blocks super 1.0 level 5, 128k chunk, algorithm 2 [3/3] [UUU]

      

unused devices: <none>

```

Auch nach der Aktivierung des "laptop_mode" bleiben die Schreibzugriffe.

Interessanterweise wird nicht auf der Ext4 Rootpartition geschrieben. (sdd1)

Ein Kurztest auf meinem Netbook zeigt ein etwas anderes Verhalten. Hier wird sauber alle 5 Sekunden von jbd2/sda4-8 ein Schreibzugriff abgestzt. Auch mit aktiviertem laptop_mode und keinen Programmen die schreiben sollten.

Kann sich irgendjemand das verhalten erklären? Ich würde es gerne meinem Server, dem PC im Wohnzimmer und meinem Netbook austreiben aus Lärm und Stromspargründen.

Mfg mknjc

----------

## Josef.95

Hi

Ist es eventuell nur das normale polling von udisks?

Schalte das doch mal testweise ab: 

```
$ udisks --inhibit-all-polling
```

 und schau ob sich was ändert.

Bei mir ist dieses polling zb auch auf der HDD LED sichtbar seitdem ich ein via S-ATA angeschlossenes CD-ROM Laufwerk mit im Rechner hab. Doch real periodisch wiederholende Schreib oder Lesezugriffe  gibt es hier nicht.

----------

## Hollowman

Hi

Versuch doch mal mit lsof raus zu bekommen wo er hin schreibt.

Sebastian

----------

## mknjc

Danke für die Antworten.

 *Quote:*   

> Ist es eventuell nur das normale polling von udisks?

 

Udisks ist nichtmal installiert.

 *Quote:*   

> Versuch doch mal mit lsof raus zu bekommen wo er hin schreibt.

 

Hm kannst du mir kurz erklären wie ich das mit lsof herausfinden kann. Es zeigt mir alle offenen Dateien an ok... Aber die auf die geschrieben wird? Ich hab grad beim Man durchgucken nichts finden können.

```
Ragnarok-Server ~ # lsof | grep md127

md127_rai  1934 root  cwd       DIR    8,49     4096       2 /

md127_rai  1934 root  rtd       DIR    8,49     4096       2 /

md127_rai  1934 root  txt   unknown                          /proc/1934/exe
```

Das sieht nicht sinnvoll aus...

PS: Ich hab auch nochmal das Raid mit noatime Eingehangen. Keine Verbesserung...

Mfg mknjc

----------

## musv

Ich klink mich hier auch mal ein. Auf meinem Notebook stört mich das ebenfalls gewaltig. Eine Lösung hab ich bisher auch noch nicht.

Verdächtige Kandidaten:

- Syslog

- Cups

----------

## V10lator

 *musv wrote:*   

> Ich klink mich hier auch mal ein. Auf meinem Notebook stört mich das ebenfalls gewaltig.

 Jetzt wo ihr das sagt fällt mir das auch auf, jedoch nur auf dem Netbook, nicht auf dem Desktop.

 *Quote:*   

> Verdächtige Kandidaten:
> 
> - Syslog
> 
> - Cups

 

Cups ist bei mir weder auf dem Netbook, noch auf dem Desktop, fällt also erstmal weg.

Auch syslog möchte ich aussortieren da dieser auch auf dem Desktop läuft.  :Wink: 

Ich denke hier geht es eher um /tmp oder so, da ich auf dem Desktop vermehrt auf tmpfs setze. Um genau zu sein benutzt der Desktop PC tmpfs für folgende Verzeichnisse:

/tmp /var/run /var/lock

----------

## mknjc

Leider kann es bei mir daran auch nicht liegen denn diese Dienste sind nicht installiert bzw. für den Test ausgeschaltet habe.

/tmp liegt auch schon in einem tmpfs...

Wenn ich das Dateisystem Readonly einhänge hören die Zugriffe auf es liegt also nicht am Raidlayer sondern am Dateisystem oder den laufenden Programmen.

Ich gehe mal davon aus das die anderen Kernelkomponenten nicht dauerhaft drauf Zugreifen.

init - Wird die Zugriffe auch nicht erzeugen. Warum sollte es?

sshd - Wenn sich jemand ein bzw. ausloggt vielleicht aber wenn keine Netzwerkverbindung besteht sollte da auch kein Zugriff stattfinden.

bash - Läuft nicht wenn ich nicht eingeloggt bin. Zugriffe bleiben.

agetty - Soweit ich das verstanden hab ist das der "Login Dienst" der einen auf dem Virtuellen Terminal begrüßt. Es ist kein Bildschirm und keine Tastatur angeschlossen warum sollte der also Zugriffe erzeugen?

udevd - Grade zum Testen beendet... Zugriffe bleiben.

Es bleibt also nur noch das Dateisystem selber. Dafür spricht auch das ich auf meinem Desktop und meinem Netbook (Beide ext4) andere Zugriffsmuster habe als auf dem Server (xfs)

Warum das Dateisystem aber darauf kommt es müsste winzig kleine Blöcke alle 5-10 sek wegschreiben ist mir ein Rätzel...

Mfg mknjc

----------

## mrsteven

Ich weiß, dass ext3 eine Mount-Option namens commit unterstützt, die angibt wie oft das Journal (zur Integritätssicherung bei unsauberem Herunterfahren) geschrieben werden soll. Für XFS habe ich auf die Schnelle nichts derartiges gefunden.

Aber eventuell ist auch das hier interessant für dich: http://www.lesswatts.org/tips/disks.php

Damit meine ich insbesondere die Einstellungen in /proc/sys unter "The VM writeback time".

----------

## musv

 *mrsteven wrote:*   

> Für XFS habe ich auf die Schnelle nichts derartiges gefunden.

 

Bei xfs gibt's die Mount-Option delaylog. Damit können analog zu Ext3/Ext4 und Reiserfs multiple asynchrone Dateitransaktionen im Speicher gehalten werden anstatt sie permanent zu schreiben, was die IO-Zugriffe ziemlich minimieren sollte.

----------

## mknjc

Ok danke für die Tipps ihr beiden.

Doch weder der Laptopmode, noch die writebacktime noch delaylog bringt irgendeine Verbesserung.  Das hätte mich auch sehr gewundert denn es gibt ja nichts und niemanden der auch nur irgendwas schreiben könnte.

Ich werde das Gefühl nicht los das es irgendein "Kernelbug" ist.

Ich probiere mal auf meinem Virtuellen Testsystem (da läuft genauso wenig, selbes Problem, auf ext4 Zugreifender Kernelthread ist "sync_supers") den 2.6.32er Kernel aus... Ma sehen was da wird...

Mfg mknjc

----------

## mknjc

Ok dort das selbe Problem... Ich weiß nicht mehr weiter...

Mfg mknjc

----------

## musv

 *mknjc wrote:*   

> Ich werde das Gefühl nicht los das es irgendein "Kernelbug" ist

 

Dann ist der aber schon ewig drin. Denn dieses Festplattenklicken im Abstand von ein paar Sekunden hatte ich schon auf meinem früheren Notebook vor 5 Jahren. Ich denke auch, dass du das Dateisystem ausschließen kannst. Ich hatte

früher:

- Root + Home: Reiserfs

später:

- Root + Home: Reiser4

jetzt:

- Root: Reiser4

- Home: xfs

- /tmp: tmpfs

Und bei allen Kombinationen gab's die Festplattenzugriffe. Bei meinem Desktoprechner hör ich die andauernden Zugriffe nicht, die werden aber trotzdem genauso vorhanden sein.

----------

## mknjc

Ok 2.6.32 ist Ende 2009 herausgekommen. D.h. seit über einem Jahr gibt es im Kernel warscheinlich irgendwo im VFS Bereich einen Bug der dafür sorgt das alle 5-10 Sek. auf das Journal(?) geschrieben wird. ODER eins von den drei Programmen (agetty, init, sshd) hat einen Bug der dafür sorgt dass das System alle 5-10 Sek. schreibt obwohl die Prozesse nichts zu tun haben.

Ich weiß nicht was mir lieber wär...

Mfg mknjc

----------

## ChrisJumper

lsof, zeigt die Programme die auf ein Verzeichnis (lsof /home/) oder Device (lsof /dev/sda1) zugreifen. lsof kann man auch für Sockets (Netzwerk, IP+Port, also lsof -i @127.0.0.1:631) verwenden. Verwendest du allerdings Raids, kann ich in dem Fall leider keine Erfahrungen beisteuern. Könnte es vielleicht ein interner Raid-Overhead sein der die Festplatten prüft (heartbeat)? Oder ein EXT4-Prozess der die Positionen optimiert (defragmentiert oder die Zugriffszeit verbessert), oder ein Programm das einfach nur Indexiert (z.B. updatedb)?

In der Regel achte ich leider nicht auf die Festplattenlampe. Vielleicht hilft auch ein Blick in Powertop. Es ist zwar in erster Linie für Intel-Prozessoren, hat aber einige Einstellungs Tipps für den Kernel oder die Systemkonfiguration zum Stromsparen für das laufende System parat.

Aktuell lege ich gerne nicht benutzte Festplatten mit hdparm -y /dev/sdX schlafen. Das funktioniert hier auch wunderbar. Bei einem erneuten Zugriff dauert es etwas länger bis die Platte wieder anläuft aber es zeigt das bei mir auf diesen nicht-system-relevanten Partitionen kein 5-Sek-Geist herum schleicht (Kernelbug!).

Vielleicht probiert ihr einfach diverse Verdächtige in ein tempfs-Ram-Verzeichnis auszulagern (Sofern man weiß das es keine wichtigen Daten sind die dabei verloren gehen können).

 *Quote:*   

> Ok 2.6.32 ist Ende 2009 herausgekommen.

 

Gibt es einen Grund das du diesen alten Kernel noch verwendest? Bei mir läuft aktuell 2.6.37. Ich hoffe doch du verwendest wenigstens 2.6.32-r19, da dieser am 7. Sept. 2010 eine schwerwiegenden Sicherheitslücken behob - mit welcher sich unbefugte Remote über das Netzwerk dein System unter den Nagel reißen (könnten).

----------

## mknjc

Nein nein ich verwende aktuell linux-2.6.38-hardened-r5 den 32er hab ich nur zum Testen genommen doch auch da hatte ich das Problem...

Ein reiner Raidoverhead ergibt für mich kein sinn denn die Zugriffe hören ja auf wenn ich das Dateisystem Readonly mounte.

Warum sollte das xfs irgendwelche Optimierungen durchführen? Dann soll er doch jedenfalls was dazu sagen oder das sollte irgendwo einstellbar sein...

```
Ragnarok-Server ~ # hdparm -y /dev/sd[a-c] ; sleep 10 ; hdparm -C /dev/sd[a-c]

/dev/sda:

 issuing standby command

/dev/sdb:

 issuing standby command

/dev/sdc:

 issuing standby command

/dev/sda:

 drive state is:  active/idle

/dev/sdb:

 drive state is:  active/idle

/dev/sdc:

 drive state is:  active/idle

```

Hier mal zum Test einfach die Festplatten in den sleep gelegt. Man sieht: Innerhalb von zehn Sekunden werden sie wieder aufgeweckt. Das spart nicht unbedingt Energie..

Naja auf der Platte liegt /var also liegt da auch was "Systemwichtiges" aber mir geht nicht in den Kopf rein warum er da dauernd rumschreiben muss wenn doch garkein Prozess läuft...

----------

## musv

Hier hatte sich jemand schon mal Gedanken dazu gemacht:

https://forums.gentoo.org/viewtopic-t-371889.html

----------

## musv

Um den Thread mal nicht ganz sterben zu lassen, mal wieder ein paar kleine Erkenntnisse.

Ich hab jetzt mal auf meinem Netbook gkrellm bemüht. Mein Netbook hat 4 Partitionen:

sda1: boot (Ext2)

sda2: swap (sich selbst)

sda3: root (Reiser4)

sda4: home (XFS)

Alle 2-10 Sekunden hör ich ein Klacken der Festplatte. Es werden dann meist 5-8 kb auf die Platte geschrieben.

Tja, und jetzt kommt das Interessante daran: 

Die eigentlich verdächtigte Root-Partition ist mucksmäuschenstill. Stattdessen erfolgen die Schreibvorgänge auf der Home-Partition. Und um die Forschung noch weiter zu treiben. Mein Window-Manager ist e16 - also kein Desktop-Environment (Gnome/KDE). Allerdings logge ich mich per KDM ein. Gkrellm hab ich beendet, die Festplatte schreibt trotzdem munter weiter. Außer e16 selbst war sonst keine weitere grafische Anwendung (nicht mal ein Terminal) geöffnet. 

Beende ich e16 und stoppe KDM, hört das Klicken auf. Starte ich e16 über startx aus der Konsole, ist das Klicken wieder da. Allerdings weiß ich eigentlich, dass der e16 nicht permanent in sein Home-Verzeichnis schreibt. 

Auf meinem Desktoprechner hab ich nahezu dieselbe Konfiguration (KDM, e16). Nur ist da das Dateisystem auf Home JFS. Auch da sind die sporadischen Zugriffe vorhanden. Nur sind hier die Zeitabstände größer (bis 20 Sekunden).

So, ich hoffe, ich hab mal wieder ein paar Ideen auf der Suche nach einem leiseren Rechnerbetrieb gegeben.

----------

## Rotanoser

erinnert sich an den Ausspruch von Albert Einstein der momentan ja offensichtlich gerade wieder doppelt wichtig wird:

"Wenn alles Mögliche ausscheidet, dann fasse das Unmögliche ins Auge."

Nun was will ich wohl damit sagen? Lernt endlich kriminell zu denken, denn die Frage nach dem "Wer" ist zweitrangig und klärt sich vielleicht ganz nebenbei, denn viel wichtiger ist das "Warum". Also warum sollte "Etwas" permanenten Schreibzugriff auf die Platten von bis zu 6 Jahre alten Computern nehmen? Und warum ist dieser "Effekt" bei neuen Netbooks besonders ausgeprägt? Vielleicht um (Index-)Daten zu sammeln? Man wacht endlich auf, hier sammeln Kriminelle vollautomatisiert Daten ein, denn dass das Dateisystem selbst die Schreibzugriffe initiiert ist ja wohl mehr als unbefriedigend. Nach meinen Erfahrungen erfolgen die Zugriffe physikalisch über heimlich implementiertes Mesh WLAN nach IEEE 802.11s(seht ruhig mal unter wikipedia nach aber verschluckt euch nicht bei so vo viel krimineller Dreistigkeit) oder heimlich implementiertes Powerline(Datentransfer über das 230 V Stromnetz) oder neuerdings offensichtlich auch über NFC oder Hochfrequenzfunk mit 40 GHz! Leider weiß ich ganz genau wovon ich da rede denn ich habe durch dieses Parasitengesindel ordentlich Federn(Datenverluste) gelassen bis ich wusste woher der Wind weht!

Vielleicht kann mir ja endlich einer von euch Könnern(und das meine ich nicht ironisch, denn viele von den angeführten Prüfmöglichkeiten kannte ich leider gar nicht, da ich nur ein einfacher "Techniker" bin) sagen was genau "bdi-default" ist und normalerweise tut! Nehmt es mir nicht übel aber im ersten Moment klingt das für mich schon wie eine Abkürzung für "Bundesministerium des Innern"(ja ich weiß dass die sich normalerweise "BMI" abkürzen). Denn vielleicht interessiert euch ja, dass mittlerweile feststeht dass bei Verwendung manipulierten Ram's(z.B. augeliefert von Hynix oder Samsung) "bdi-default und sync_supers" einfach weiterlaufen wenn man mit partimage unter "sysrescuecd" ein image zieht und bei sauberem Ram eben nicht! Nach Einsatz von Gleich- und Wechselspannungstiefpassfilternin der Stromversorgung (Grenzfrequenz: 150 Hz und 50 KHz) kann ich momentan zumindest schon mal sagen dass angeschlossene externe USB-Festplatten endlich wieder normales Verhalten zeigen, also ohne zusätzliche Funkzugriffe nur arbeiten wenn wenn auch wirklich ein Vorgang initiiert wurde!

So, dass muss erst mal reichen.

Es wäre nett wenn nach dieser zugegeben nicht sehr erfreulichen Meldung noch jemand eine Erklärung zu BDI-default abgibt wenn es denn überhaupt eine "normale" gibt!

----------

## mrsteven

Zu bdi-default das hier: http://lwn.net/Articles/396757/

Der Thread wird in /usr/src/linux/mm/backing-dev.c gestartet und ist normalerweise dazu da, weitere Threads zu starten, die dann noch nicht geschriebene Änderungen an Dateien vom RAM auf die Platte übertragen (Write Behind Caching). Wenn da irgendwas (vermutlich schon e16) auf die Platte schreibt, ist es vollkommen normal, dass bdi-default, sync_supers u.ä. aktiv werden. Damit schließe ich ein Rootkit nicht unbedingt aus, aber wahrscheinlicher ist schlicht und ergreifend ein Bug.

Der Rest von dem Posting über mir kommt mir ziemlich an den Haaren herbeigezogen vor. Just because you are paranoid doesn't mean they are after you...

----------

## firefly

Zumindestens bei laptop festplatten könnte es auch sein, dass der Lesekopf der festplatte zyklisch in die Parkposition gebracht wird, wenn nicht gerade Daten gelesen oder geschrieben werden.

AFAIK ist das eine Vorsichtsmaßnahme, um, den Lesekopf vor einem Headcrash zu sichern, falls der Laptop mal im laufenden betrieb unerwartet runterfallen sollte.

----------

## bbgermany

Hi,

ich hab mal ein bissle Google bemüht und bin da auf dieses Blog gestoßen: http://www.fukurama.org/wordpress/2008/09/15/festplattenzugriffe-unter-linux-ubuntu-minimieren/

Eventuell hilft es zumindest genau den schuldigen ein wenig einzugrenzen. Es sind auch ein paar Lösungsansätze da.

MfG. Stefan

----------

## Rotanoser

An dieser Stelle erst mal vielen Dank für die äußerst nützlichen Antworten zur letzten Anfrage.

Die vereinzelt als beleidigend empfundenen "Randbemerkungen" ignoriere ich einfach mal, denn der Grund für mein erneutes posting ist wichtiger.

Dafür möchte ich einleitend noch einmal auf den oben zitierten Ausspruch von Albert Einstein verweisen, denn dieser liefert zusammen mit dem ursprünglichen vorhandenen Zwischenergebnis: "die Plattenzugriffe werden vom Dateisystem selbst initiiert" den richtigen Lösungsansatz! 

Die richtige Frage lautete schlicht: 

Wie ist es möglich dass das Dateisystem selbst die Zugriffe initiirt?

Antwort: Indem ein illegales Datenabgriffsystem direkt in der Festplatte sitzt!

Denn das haben alle sogenannten Experten des "Bevölkerungsschutzes" in den vergangenen Jahren wohl wiedermal einfach "übersehen"? Ich rede von der Bestückung vieler Festplatten mit einem illegalen, berührungslosen rein magnetischen Abgriffsystem! Sendereichweite unbekannt! Minimum müssen aber 10-20 Meter sein da der Aufwand sonst gar keinen Sinn macht.

Unangenehm aufgefallen sind dabei bisher die Hersteller: Seagate, Samsung und teilweise WD(Western Digital). Die magnetische "Antenne" sitzt als aufgeklebtes Metalstück direkt unterm(im) Herstelleraufkleber! Eine aus dem ASUS Netbook HA1005 stammende Seagate-Platte habe ich daraufhin komplett geöffnet und gesehen dass es eine Art 2x2x0,3cm dicken "Spezialschaumstoffaufkleber mit Folienkunststoffantenne" im Innern der Platte gab der die Verbindung zwischen einem elektronischen Controller und dem Gehäuseinneren unter der magnetischen Aussenantenne herstellte. Bei den 2,5 Zoll Platten von Seagate ist die Aussenantenne ein flächiger Aufkleber, Bei den 2,5 Zoll Platten von Samsung ist es ein rund 2 mm dickes, aufgeklebtes Halbkreisstreifenblech und bei den 3,5 Zoll Platten des selben Herstellers ein flächiges 2 mm dickes Blech welches fast über die gesamte Plattenoberseite geht! Bei WD war man besonders clever und hat die Antenne teilweise gleich als Dünnblechherstelleraufkleber konzipiert! Da dieser aber so dünn ist musste der magnetisch wirksame Legierungsanteil offensichtlich auch besonders hoch sein und das sieht man natürlich dadurch hervorragend. Das Metall ist dann sehr dunkel!

Allen die es nicht glauben wollen empfehle ich einfach mal die Entfernung dieser Oberflächenantennen, denn dies hat natürlich keinerlei Auswirkung auf die Funktion der Festplatten. Im Gegenteil ich hatte sogar den Eindruck dass das System hinterher schneller lief! 

Sauber war übrigens folgendes SATA-Festplatten-Model von Western Digital: "WD 3200 BEVT".

Aufgeflogen ist dieser ganze Mist weil ich mich seit mai 2011 mit einem neuen völlig "verseuchten" Macbook Pro rumärgere und den verbauten illegalen Quatsch Stück für Stück lahmgelegt habe. Die bisherige Ausbeute kann sich absolut sehen lassen:

manipulationsoptimierter Ram von Hynix, Festplatte mit internem magnetischen Abgriffsystem von Seagate, 1,48 GHz Antenne im Akku im rechten Teil unterm Touchpad, Verdacht auf 2x magnetisches Abgriffsystem(Stahlpassfedern im Alugehäuse: 1x neben der Festplatte und 1x unterm Akku), Verdacht auf mindestens 2x Funkssystem mit >40GHz --> der "Versand" erfolgt offensichtlich durch die 7 mm Öffnungen im Alugehäuse an den Fußdruckpunkten der Unterschale, verseuchter Betriebssystemdatenträger(z.B. Debianinstallationssperre im EFI-Bios und zusätzlich scriptgesteuert im Betriebssystem OS 10.6.6) aber der absolute Knaller war das mit Abgriffsystemen vollgestopfte Netzteil(Powerline und chips mit der Aufschrift G4 und G5 die auf die Übertragungsstandards 4G und 5G hindeuten -> viel Spaß beim Lesen der Wikipediaartikel zu WPAN und 5G).

----------

## mrsteven

Egal was du nimmst, über die Dosis solltest du nochmal nachdenken...  :Rolling Eyes: 

----------

## franzf

Die Festplattenhersteller haben es tatsächlich auf uns Verbraucher abgesehen. Die drehenden Magnetplatten erzeugen nicht hörbare Geräusche, die aber von unserem Gehirn wahrgenommen werden können und Endorphinausschüttung auslösen. Da machen alle Hersteller mit, und sie versuchen sich gegenseitig zu überbieten. Genauso wie bei Fertigfressi/Chips/..., wo mit speziellen "geheimen" Geschmackverstärker-Aroma-Mischungen Sucht erzeugt wird, und ständig wird verbessert, damit man der Konkurrenz die Esser stielt.

Das erklärt auch, warum jeder seinen ganz bestimmten Lieblingsfestplattenhersteller hat und nichts anderes will. Ja - Festplatten machen süchtig! Aus dem Grund stell ich gerade alles auf SSDs um! Und hier nehm ich natürlich nur die Crucial m4! Crucial macht glücklich  :Smile: 

----------

## musv

Ich hab's irgendwie in letzter Zeit mit angehenden Threadleichen.

Ich glaub, ich hab zumindest bei mir den Fehler gefunden. lsof /home hat's gebracht. 

```
  lsof /home/

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF       NODE NAME

e16     13463   sm  cwd    DIR    8,4     4096        132 /home/sm

e16     13463   sm    1w   REG    8,4        0        134 /home/sm/.xsession-errors

e16     13463   sm    2w   REG    8,4        0        134 /home/sm/.xsession-errors

gkrellm 13488   sm  cwd    DIR    8,4     4096        132 /home/sm

gkrellm 13488   sm  mem    REG    8,4     1556        480 /home/sm/.local/share/mime/mime.cache

gkrellm 13488   sm    1w   REG    8,4        0        134 /home/sm/.xsession-errors

gkrellm 13488   sm    2w   REG    8,4        0        134 /home/sm/.xsession-errors

urxvt   13531   sm  cwd    DIR    8,4     4096        132 /home/sm

urxvt   13531   sm    0w   REG    8,4        0        134 /home/sm/.xsession-errors

urxvt   13531   sm    1w   REG    8,4        0        134 /home/sm/.xsession-errors

urxvt   13531   sm    2w   REG    8,4        0        134 /home/sm/.xsession-errors

bash    13532   sm  cwd    DIR    8,4     4096        132 /home/sm

opera   13682   sm  cwd    DIR    8,4     4096        132 /home/sm

opera   13682   sm  mem    REG    8,4    78844 1080829068 /home/sm/.opera/cache/assoc002/sesn/opr0SXGG.000

opera   13682   sm    1w   REG    8,4        0        134 /home/sm/.xsession-errors

opera   13682   sm    2w   REG    8,4        0        134 /home/sm/.xsession-errors

opera   13682   sm    4uW  REG    8,4        0  538165048 /home/sm/.opera/lock

opera   13682   sm    8r   REG    8,4   487959 1080109321 /home/sm/.opera/skin/metal_blue-3_1.zip

opera   13682   sm   23uW  REG    8,4     1024 1611843665 /home/sm/.opera/mail/omailbase.dat

opera   13682   sm   24uW  REG    8,4     1024       5141 /home/sm/.opera/mail/indexer/message_id

urxvt   13840   sm  cwd    DIR    8,4     4096        132 /home/sm

urxvt   13840   sm    0w   REG    8,4        0        134 /home/sm/.xsession-errors

urxvt   13840   sm    1w   REG    8,4        0        134 /home/sm/.xsession-errors

urxvt   13840   sm    2w   REG    8,4        0        134 /home/sm/.xsession-errors

bash    13841   sm  cwd    DIR    8,4     4096        132 /home/sm

lsof    13855   sm  cwd    DIR    8,4     4096        132 /home/sm

lsof    13856   sm  cwd    DIR    8,4     4096        132 /home/sm
```

Und da gab's dann gleich mehrere Übeltäter. Gkrellm schreibt seine Fehler nach .xsession-errors. Opera versucht über den Mailclient irgendwas zu schreiben.

Update:

War wohl zu voreilig. Firefox cached auch permanent auf Platte. Schließ ich sämtliche Browser, Konsolen und andere Anwendungen, klackert's trotzdem.  :Sad: 

----------

## Klaus Meier

Ich kann mich entsinnen, dass ich diesen Effekt mal hatte, als ich reiser3 benutzt habe. Mit dem Wechsel zu ext3 ist er verschwunden. Aber wenn ich mir das so durchlese, dann ist das auch keine Erklärung/Lösung.

----------

## slick

Ich denke auch das Problem sollte am Dateisystem selbst zu suchen sein. Ich habe hier ext4 ohne Journal (mke2fs -t ext4 -O ^has_journal /device) und kann dieses Verhalten nicht beobachten.

----------

## schmidicom

Ich habe diesen "Bug" bei mir auch schon bemerkt und scheinbar haben die Kernelentwickler dem nun ein Ende gesetzt.   :Very Happy: 

 *Quote:*   

> Durch einige Umbauten am VFS (Virtual File System) und dem darauf aufbauenden Dateisystemcode konnten die Entwickler den Kernel-Daemon pdflush entfernen, der bislang alle fünf Sekunden das Schreiben der Superblocks ausgelöst hat, wenn es Änderungen an den dort gespeicherten Daten gab. Dieses regelmäßige Aufwachen war unter Stromsparaspekten ungeschickt.

 

http://www.heise.de/open/artikel/Kernel-Log-Was-3-6-bringt-1-Dateisysteme-und-Storage-1671225.html

----------

## DirtyHairy

Eine ganz profane Möglichkeit: sind die fraglichen Partitionen eventuell ohne noatime gemounted?

----------

## musv

Hab bei mir mal iotop installiert. Das Teil zeigt an, welcher Prozess Schreib- und Lesezugriffe hervorruft. 

Die Festplattenzugriffe sind mittlerweile so gut wie verschwunden. Ab und zu cached btrfs noch was. Das war's dann aber auch schon.

----------

