| View previous topic :: View next topic |
| Author |
Message |
mknjc
n00b
Joined: 23 May 2011
Posts: 9
|
 Posted: Mon May 23, 2011 5:00 am Post subject: Dauerhafte Festplattenzugriffe |
 |
|
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:
| Code: | 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:
| Code: | 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:
| Code: | 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 |
|
| Back to top |
|
 |
Josef.95
Advocate
Joined: 03 Sep 2007
Posts: 4693
Location: Germany
|
| Posted: Mon May 23, 2011 8:50 am Post subject: |
|
|
Hi
Ist es eventuell nur das normale polling von udisks?
Schalte das doch mal testweise ab: | Code: | | $ 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. |
|
| Back to top |
|
|
Hollowman
Guru
Joined: 19 Apr 2007
Posts: 584
|
| Posted: Mon May 23, 2011 10:59 am Post subject: |
|
|
Hi
Versuch doch mal mit lsof raus zu bekommen wo er hin schreibt.
Sebastian |
|
| Back to top |
|
|
mknjc
n00b
Joined: 23 May 2011
Posts: 9
|
| Posted: Mon May 23, 2011 12:16 pm Post subject: |
|
|
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.
| Code: | 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 |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3369
Location: de
|
| Posted: Mon May 23, 2011 2:46 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
V10lator
Apprentice
Joined: 11 Jul 2004
Posts: 207
|
| Posted: Mon May 23, 2011 2:59 pm Post subject: |
|
|
| 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. 
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 |
|
| Back to top |
|
|
mknjc
n00b
Joined: 23 May 2011
Posts: 9
|
| Posted: Mon May 23, 2011 4:37 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
mrsteven
Veteran
Joined: 04 Jul 2003
Posts: 1939
|
| Posted: Mon May 23, 2011 5:28 pm Post subject: |
|
|
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". |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3369
Location: de
|
| Posted: Mon May 23, 2011 7:38 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
mknjc
n00b
Joined: 23 May 2011
Posts: 9
|
| Posted: Mon May 23, 2011 8:26 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
mknjc
n00b
Joined: 23 May 2011
Posts: 9
|
| Posted: Mon May 23, 2011 8:34 pm Post subject: |
|
|
Ok dort das selbe Problem... Ich weiß nicht mehr weiter...
Mfg mknjc |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3369
Location: de
|
| Posted: Mon May 23, 2011 9:07 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
mknjc
n00b
Joined: 23 May 2011
Posts: 9
|
| Posted: Mon May 23, 2011 9:27 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2403
Location: Germany
|
| Posted: Mon May 23, 2011 9:52 pm Post subject: |
|
|
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). |
|
| Back to top |
|
|
mknjc
n00b
Joined: 23 May 2011
Posts: 9
|
| Posted: Tue May 24, 2011 5:40 am Post subject: |
|
|
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...
| Code: | 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... |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3369
Location: de
|
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3369
Location: de
|
| Posted: Fri May 27, 2011 10:25 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Rotanoser
n00b
Joined: 29 Aug 2011
Posts: 2
|
| Posted: Mon Aug 29, 2011 10:10 pm Post subject: so viele schlaue Leute aber keiner |
|
|
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! |
|
| Back to top |
|
|
mrsteven
Veteran
Joined: 04 Jul 2003
Posts: 1939
|
| Posted: Tue Aug 30, 2011 12:18 am Post subject: |
|
|
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... |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Tue Aug 30, 2011 6:17 am Post subject: |
|
|
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.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
bbgermany
Veteran
Joined: 21 Feb 2005
Posts: 1844
Location: Oranienburg/Germany
|
| Posted: Tue Aug 30, 2011 6:55 am Post subject: |
|
|
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
_________________
Desktop: Ryzen 5 5600G, 32GB, 2TB, RX7600
Notebook: Dell XPS 13 9370, 16GB, 1TB
Server #1: Ryzen 5 Pro 4650G, 64GB, 16.5TB
Server #2: Ryzen 4800H, 32GB, 22TB |
|
| Back to top |
|
|
Rotanoser
n00b
Joined: 29 Aug 2011
Posts: 2
|
| Posted: Tue Sep 20, 2011 4:00 pm Post subject: |
|
|
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). |
|
| Back to top |
|
|
mrsteven
Veteran
Joined: 04 Jul 2003
Posts: 1939
|
| Posted: Tue Sep 20, 2011 5:39 pm Post subject: |
|
|
Egal was du nimmst, über die Dosis solltest du nochmal nachdenken...  |
|
| Back to top |
|
|
franzf
Advocate
Joined: 29 Mar 2005
Posts: 4565
|
| Posted: Tue Sep 20, 2011 6:31 pm Post subject: |
|
|
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  |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3369
Location: de
|
| Posted: Wed Jun 20, 2012 9:09 pm Post subject: |
|
|
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.
| Code: | 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.  |
|
| Back to top |
|
|
|
Deutsches Forum (German)
