Xubuntu 7.10 Harddisk beweegt elke minuut

[oenboek]

Ik heb een PC die ik als mediacenter wil gebruiken bijna volledig klaar. De volgende stap is de harddisk vervangen door een compactflash kaartje. Maar ik wil op dat kaartje zo weinig mogelijk schrijven (los van de vraag of dat kwaad kan of niet). Daarom heb ik al de tijdelijke directories als tmpfs aangemaakt, staat er bij elk filesysteem noatime en zijn alle logs die ik terugvind gedisabled of verwijzen ze naar een tmpfs directory.
Maar toch hoor ik de kop van de harddisk minstens 1 keer per minuut bewegen. Ik vind in de opvolging van processen geen vreemde processen, ik zie geen open files. Kortom, ik weet absoluut niet wat ik moet doen om die HD zijn kop te laten (stil) houden.
Wat draait er voor de rest: WICD, MPD, GMPC. Maar zelfs met deze toepassingen gestopt schudt die HD af en toe zijn kop.
Suggesties om die kop stil te houden?

[Verwijderd]

Misschien is het een hardware matige operatie die je (waarschijk) niet kunt laten stoppen.

Want hoevaak doet hij dit precies? Als hij dit om voorspelbare invallen doet dan denk ik dat dat het is..

[ Voor 37% gewijzigd door Verwijderd op 07-01-2008 19:31 ]

[Sebazzz]

Als een HD niet door het OS uitgeschakeld wordt dan gaat hij diagnostische operaties uitvoeren, zoals scannen voor bad sectors en dan eventueel een reserve sector toewijzen aan een rotte plek.

[Shuriken]

Ik heb zelf een systeempje vanaf een usb stick draaien.

In fstab heb ik een aantal zaken aangepast:

code:

tmpfs             /tmp             tmpfs     defaults,noatime 0 0
tmpfs             /var/lock         tmpfs     defaults,noatime 0 0
tmpfs             /var/log         tmpfs     defaults,noatime 0 0
tmpfs             /var/run         tmpfs     defaults,noatime 0 0
tmpfs             /var/tmp         tmpfs     defaults,noatime 0 0

daarna een scriptje gemaakt wat bij reboot/shutdown de boel naar een directory copieert. En een ander scriptje wat de boel bij booten weer terug zet in ramdisk.

Dat moet voldoende zijn.

[Verwijderd]

niks

[ Voor 90% gewijzigd door Verwijderd op 07-01-2008 19:33 ]

[joopv]

Moderne HD's hebben zo'n hoge trackdichtheid dat regelmatige calibratie nodig is vanwege veranderingen van afmetingen ten gevolge van temperatuursveranderingen.

Verder lopen er inderdaad diverse interne housekeeping processen.

Zet de HD eens alleen op voeding zonder een controller aan te sluiten. Wat hoor je dan?

[ Voor 16% gewijzigd door joopv op 07-01-2008 19:37 ]

[oenboek]

@Shrimp O Vis
De tijd tussen 2 bewegingen is niet 100% regelmatig. Soms na 5sec, dan na 10, en dan weer pas na een minuut. Er zit geen regelmaat in, het geluid lijkt wel telkens ongeveer hetzelfde.
@Shuriken
Ik heb min of meer dezelfde dingen als tmpfs staan in fstab:
/dev/ram0 /tmp tmpfs defaults,nodev,nosuid 0 3
/dev/ram1 /var/run tmpfs defaults,nodev,nosuid 0 3
/dev/ram2 /var/log tmpfs defaults,nodev,nosuid 0 3
@joopv
Ik heb de HD eens aangesloten zonder controller, dan is er niets te horen buiten het draaien. Deze prima suggestie sluit hardware uit. Het zit dus ergens in Xubuntu...

[deadinspace]

oenboek schreef op maandag 07 januari 2008 @ 19:27:
Maar toch hoor ik de kop van de harddisk minstens 1 keer per minuut bewegen.

Ik vermoed dat dat ext3's journal commit is. Welk filesystem gebruik je op die HD, en met welke opties is die gemount?

... ik zie geen open files.

Dan moet je eens

lsof

doen

[oenboek]

Dit is een extract van fstab voor de harddisk:
# /dev/sda1
UUID=f7359f0e-d0de-48a0-83f5-842ae1a9d905 / ext3 defaults,noatime,errors=remount-ro 0 1
# /dev/sda2
UUID=ccd109a8-5467-4519-bb62-2b5040890f3c none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,noatime,exec 0 0
De swap moet ook nog in ram komen, maar die wordt niet gebruikt tot nu toe (er zit 1 MB RAM in de machine).

lsof laat inderdaad een hele resem files zien. Maar ik heb geen idee welke die diskbewegingen kan veroorzaken. Ik zal de afdruk van lsof enkele malen in een bestand dumpen en dan de filegroottes vergelijken. Dat wijst misschien al in een richting.

[deadinspace]

oenboek schreef op maandag 07 januari 2008 @ 21:40:
# /dev/sda1 UUID=f7359f0e-d0de-48a0-83f5-842ae1a9d905 / ext3 defaults,noatime,errors=remount-ro 0 1

Ext3 dus, met vrij standaard opties. Ga er maar van uit dat die periodieke harddisk activiteit de commit cycle is (standaard iets van elke vijf seconden). Zet die maar eens hoger.

lsof laat inderdaad een hele resem files zien. Maar ik heb geen idee welke die diskbewegingen kan veroorzaken. Ik zal de afdruk van lsof enkele malen in een bestand dumpen en dan de filegroottes vergelijken. Dat wijst misschien al in een richting.

Nah, ik denk niet dat je zoveel hebt aan de output van lsof. Dat die files open zijn wil ook niet zeggen dat er veel boeiends mee gebeurt.

Het was meer een geintje omdat je zei dat je geen open files zag. Na het typen van lsof zie je die namelijk wel, heul veul

[oenboek]

Ik heb de commit-waarde op 300 gezet. De eerste indruk die ik heb is dat de kop inderdaad stilstaat. Als ik er zeker van ben dat de journaling de oorzaak is, kan ik beter naar ext2 gaan. Als ik me niet vergis heeft ext2 deze journaling niet. Als ik dan nog van ext3 naar ext2 kan gaan... Maar dat zal iets voor morgen zijn.

[deadinspace]

Kan dat hele filesystem niet gewoon read-only eigenlijk? Wat staat er nog op?

[laurencevde]

Er zijn ook enkele speciaal voor flash ontworpen fs-en, zoals jffs2(in de kernel, maar mount traag en gebruikt meer geheugen op grotere partities) en yaffs2.

[Super_ik]

en mocht je het willen: ext3 kan je gewoon als ext2 mounten, verander in je fstab ext3 naar ext2

[oenboek]

@deadinspace
GMPC heeft nog bestanden nodig om config en database te bewaren. Voor de rest weet ik het niet. Ik zou de files van gmpc er nog kunnen afgooien en dan proberen ro te mounten (ik was al van plan die files op de server te bewaren). Maar dan kan ik ook geen aanpassingen meer doen. Als het systeem niets schrijft is ro niet nodig.
@laurencevde
Ik vind het handig als ik het kaartje ook standaard kan benaderen op andere PCs of bij opstarten vanaf CD. Al was het maar om fstab aan te passen om terug in rw te zetten. Andere fsen lijken me alleen zinvol als ze (veel) sneller zijn. Uitlezen van flash duurt nu lang in vergelijking met HD. Ik wil ook kunnen een image van het kaartje op HD kunnen zetten om zo ook in andere PCs te kunnen testen.
@Super_ik
Wist ik niet, ik dacht dat ik de partititie ook moest veranderen. Dat probeer ik vanavond onmiddelijk. Als dat werkt kan ik een image van de harddisk op de compact flash zetten en is mijn systeem eindelijk klaar.

[deadinspace]

oenboek schreef op maandag 07 januari 2008 @ 21:40:
De swap moet ook nog in ram komen

Dat is vrij loos natuurlijk

oenboek schreef op dinsdag 08 januari 2008 @ 12:23:
@deadinspace
Ik zou de files van gmpc er nog kunnen afgooien en dan proberen ro te mounten (ik was al van plan die files op de server te bewaren). Maar dan kan ik ook geen aanpassingen meer doen. Als het systeem niets schrijft is ro niet nodig.

Als read-only makkelijk haalbaar is dan zou ik daar voor gaan, dan wordt er gegarandeerd niks geschreven naar je flash, en kun je het systeem bijvoorbeeld ook zo uitzetten zonder netjes af te sluiten (netwerk-verbindingen e.d. even daargelaten).

Ik vind het handig als ik het kaartje ook standaard kan benaderen op andere PCs of bij opstarten vanaf CD. Al was het maar om fstab aan te passen om terug in rw te zetten.

Je kan natuurlijk dat filesystem ook gewoon on the fly read-write remounten.

[Sebazzz]

Ik heb nog een tip: Zet in fstab bij iedere ext3 of ext2 filesystem de volgende optie:

 noatime

Dan gaat ie niet iedere keer als hij een bestand opvraagt de datum veranderen van de laatste keer dat ie dat bestand heeft aangevraagd

[oenboek]

@Sebazzz
Had ik al gedaan
@Deadinspace
Kan ik doen als ik zeker ben dat het OK is. Het stoort me dat er een onbekend proces iets wegschrijft.
Swap in ram is inderdaad een contradictie...

VERVOLG
Met ext2 of met een hoge tijd voor de journaling blijft de kop toch nog bewegen.
Maar ik heb ontdekt dat er af en toe in het bestand .xsession-errors geschreven wordt. En ik heb een sterk vermoeden dat dit de dader is. Hier de inhoud die steeds weerkeert:
not trans
196
m| 10000
not rec
:images/idle-high-signal-lock.png
|idle-high-signal-lock.png
eth1: 3347898 3601 0 0 0 0 0 0 361819 2139 0 0 0 0 0 0
not trans
Hierbij is eth1 een wireless USB-stick die gecontroleerd wordt via WICD.
Intussen heb ik om dit te vermijden in het bestand /etc/X11/Xsession de lijn:
#ERRFILE=$HOME/.xsession-errors
vervangen door:
ERRFILE=/var/log/xsession-errors
waarbij /var/log een ramdisk is, dus zonder slingerende koppen.
Ik hoop dat dit helpt. Ik had het errors bestand al vervangen door een symlink naar /dev/null, maar dat wordt blijkbaar ongedaan gemaakt door het opstartscript van X11.
Hout vasthouden nu, ik herstart de koppige disk.

[BCC]

Spuit 11

[ Voor 90% gewijzigd door BCC op 08-01-2008 21:06 ]

[oenboek]

Verdorie.
X11 blijft schrijven in de file .xsession-errors, ondanks de verwijzing naar een andere file in het script. Als ik de error file verwijder, stopt het schrijven. Maar na een reboot staat die file weer terug op de foute plaats. In de dir /var/log verschijnt geen nieuwe file.
Ik heb nu echt de indruk dat na het verwijderen van de error file de kop van de HD stilstaat, al kan dat ook wishfull thinking zijn.
Het is ook zo dat in de log van WICD ook veel boodschappen van eth1 terechtkomen, maar dat is normaal denk ik omdat WICD voortdurend checkt of de link nog actief is. Die log heb ik ook in een ramdisk gezet en dat werkt perfect.
Iemand een idee hoe die .xsession-errors log te stoppen? Liefst door de oorzaak weg te nemen, desnoods door het schrijven te voorkomen.

[laurencevde]

Alles van X-apps die iets naar (sdout? en )sderr sturen komt daarin terecht, en het bestand wordt bij elke sessie opnieuw aangemaakt.
Om helemaal te voorkomen dat ernaartoe geschreven wordt moet je de rechten erop beperken: geef het een andere eigenaar, en haal schrijftoegang weg(chown root:root .xsession-errors && chmod -w .xsession-errors)
Ook kun je je sessie starten met iets als $startsessie > /dev/null. Of het loglevel aanpassen...

[gertvdijk]

oenboek schreef op dinsdag 08 januari 2008 @ 21:27:
Verdorie.
X11 blijft schrijven in de file .xsession-errors, ondanks de verwijzing naar een andere file in het script. Als ik de error file verwijder, stopt het schrijven. Maar na een reboot staat die file weer terug op de foute plaats. In de dir /var/log verschijnt geen nieuwe file.

Heb je wel eerst X neergehaald voordat je z'n config aanpaste? Een vergelijkbaar probleem krijg je namelijk ook met de logs van Apache als je die draaiend houdt en de locatie van de logfile aanpast in de config.

[oenboek]

@laurencevde
Aanpassen van de rechten werkt inderdaad, tot een reboot. Dan verandert X... terug de rechten.
Ik heb intussen gemerkt dat gdm Gnome Display Manager de X-sessies regelt. En bij gdm blijkt het onmogelijk te zijn de behandeling van .xsession-errors te beïnvloeden. Ze schrijven heel fier dat ze dat hard gecodeerd hebben als beveiliging.
Ik wil proberen gdm eruit te zwieren en rechtstreeks te vervangen door X11. Maar eerst een image nemen, ik ben niet 100% gerust in de afloop van die verwijdering.
Jouw voorstel $startsessie > /dev/null heb ik nog niet geprobeerd. De sessies worden automatisch gestart en daar moet ik de weg nog zoeken.

[Super_ik]

als je maar 1 user hebt en je wilt toch altijd meteen een desktop starten (gnome?) dan heb je gdm niet nodig nee.

[RemcoDelft]

Ik heb ooit gezocht naar een oplossing om mijn harddisk power-down te geven als ik de computer niet gebruik. Bij gebruik van ReiserFS bleek het niet mogelijk te zijn om schrijfacties te voorkomen, bij gebruik van Ext2 is het wel mogelijk om alle schrijf-acties langdurig te bufferen.
Oftewel voor CF als harddisk zal dit ook moeten kunnen, bij gebruik van EXT2.

[Rainmaker]

Misschien heel ranzige oplossing, maar als je nou in local.start (of gdmrc of hoe dat bestand ook heet), de .xsession pas verwijderd en ln -s'd naar een ramdisk?

Die 2 scripts zouden pas ná GDM moeten starten. Desnoods zet je die code in een startup script van je DM.

En anders; volume read-only mounten, dan gebeurd er zeker niks mee, ook als weet ik niet hoe GDM daarop reageert

[Sebazzz]

Rainmaker schreef op donderdag 10 januari 2008 @ 18:15:En anders; volume read-only mounten, dan gebeurd er zeker niks mee, ook als weet ik niet hoe GDM daarop reageert

Dat maakt dan toch niet uit want het is read-only hè

[Rainmaker]

Sebazzz schreef op donderdag 10 januari 2008 @ 18:17:
[...]

Dat maakt dan toch niet uit want het is read-only hè

GDM zou ook kunnen stoppen met de melding "cannot open .xsession for writing. Exiting" o.i.d. Of het terugvallen op zn ncurses interface met de melding "er is een probleem met de X-server" of het kan vastlopen na het inloggen. Of het kan een blauw scherm geven ()

Dat bedoelde ik

[Verwijderd]

ik heb er absoluut geen verstand van, maar heb zoiets eerder van iemand gehoord, en het schijnt ook een bekend probleem te wezen van (x/k/etc)ubuntu.

hiero:
http://hardware.slashdot.org/article.pl?sid=07/10/30/1742258
en hier:
http://www.thinkwiki.org/..._with_hard_drive_clicking

[BCC]

En wat gebeurt er als je er een symlink van maakt naar een ramdrive?

[oenboek]

@BCC, @Rainmaker
Ik vermoed dat vanuit rc.local een file in ram aanmaken en daarnaar een symlink leggen de enige oplossing is. Of vanuit rc.local de file read-only maken, of verwijzen naar /dev/null. Want al wat ik probeer met gdm blijkt niet te helpen.
Ik heb nog niet geprobeerd om gdm te vervangen door iets anders, ik vrees dat mijn PC volledig onbestuurbaar wordt dan. Als ik nu gdm stop vanuit een terminalvenster loopt de PC vast. Dus starten zonder is niet zonder risico. Bovendien dacht ik dat gdm gebruikt werd door de VNC-server die ik gebruik, maar dat moet ik nog eens checken. Ik zal dat wel eens proberen, maar dan moet ik eerst een image maken voor het geval mijn systeem dood valt. Voorlopig probeer ik het op te lossen via rc.local.

@gunhead
Jouw artikels gaan over powerdown etc. Het probleem hier is dat er af en toe gegevens in een bestand geschreven worden.

[Verwijderd]

BCC schreef op donderdag 10 januari 2008 @ 23:51:
En wat gebeurt er als je er een symlink van maakt naar een ramdrive?

Dat heeft toch geen zin.... Je hdd wordt toch aangestuurd om de symlink te lezen... het OS komt er dan pas achter dat het een symlink is en gaat ie naar de ram drive schrijven.

[oenboek]

Eindelijk heb ik .xsession-errors kunnen laten verdwijnen bij opstart. Dat heb ik gedaan door aan het bestand /etc/gdm/PreSession/Default een lijn "sudo rm ~/.xsession-errors" toe te voegen. Nu is het bestand er niet meer, en kan er niet meer naar geschreven worden, en moeten de koppen er niet meer voor bewegen wat de bedoeling was.
Nu moet ik eerst luisteren of de kop van de HD inderdaad stil blijft staan. Indien niet op zoek naar de volgende dader.
Dank aan allen voor de tips. Zonder de tips had ik het met superlijm moeten oplossen denk ik.

[Room42]

Echt puur uit interesse en omdat ik je graag wil begrijpen (wellicht dat je me er wijzer en verstandiger mee maakt ): Waarom wil je dit precies? Waarom mag er absoluut niet (teveel) geschreven worden?

Zonder de tips had ik het met superlijm moeten oplossen denk ik.

lol!

@Brent, hieronder:
Maar hij gaat hem vervangen door een SSD... die hoor je niet, hoor

[ Voor 13% gewijzigd door Room42 op 12-01-2008 11:55 ]

[Brent]

Ik geloof dat ie hem volledig stil wil laten zijn, en om de zoveel tijd een geluidsje is natuurlijk wel irritant.

[oenboek]

@sjaakduhuuhl
Los van de discussie of flash verslijt door te vaak schrijven, vind ik het zinloos dat er meerdere keren per minuut overbodige info weggeschreven wordt. Dus dat moest eruit. De volgende stap is ervoor te zorgen dat GMPC de coverdatabase op de server zet ipv in de user directory. Dan kan ik eventueel nog de disk als -ro mounten, maar dat is toekomstmuziek.
Nu kan ik de harddisk imagen naar de compact flash kaart. Dan nog de USB-convertor waarmee ik het geluid naar mijn DAC kan sturen in mekaar solderen en het touchscreen bestellen en kan de PC eindelijk naar de woonkamer verhuizen.

[Room42]

lol ok