Harddisk led knippert 2 keer per seconde

[Verwijderd]

Hoi,
Ik zit met een oud probleem waar ik nav het bericht over de aankomende LTS nog maar eens een forum vraag tegenaangooi. Er is een tamelijk groot topic op launchpad over dit probleem wat ik dus vervelend genoeg niet terug kan vinden.

Ik heb een servertje draaien op Lucid waarbij de harddisk led 2 keer per seconde knippert. iotop geeft geen soelaas, en ik heb al verschillende dingen geprobeerd, zoals grub/kernel parameters e.d. die in die thread als mogelijke oplossingen genoemd worden (vervelend dat ik die thread niet terugvindt nu). Veel mensen hebben dit probleem, ook op bv suse en andere distro's, en een oplossing had die (lange) thread niet de laatste keer dat ik keek.

Dus probeer ik hier mijn geluk nog maar eens.
Zijn er mensen die dit probleem kennen en zijn er misschien nog ideeen?

Ik draai weliswaar ook kde op die pc maar ook als ik die uitzet knippert de led vrolijk door.

Bedankt

edit: Thread gevonden: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607560
edit2: ik heb het trouwens ook op een andere pc, ook lucid maar dan 32 bit en daar is de frequentie 1 keer per 2 seconden, nog steeds veel dus.

[ Voor 10% gewijzigd door Verwijderd op 21-10-2011 19:15 ]

[H!GHGuY]

Doe eens

code:

echo 1 > /proc/sys/vm/block_dump
tail -f /var/log/messages
echo 0 > /proc/sys/vm/block_dump

Daar kun je zien waneer er effectief naar de disk geschreven wordt.

Een andere mogelijkheid is dat de functie van de led niet op HD activity staat, maar op load.
Zoek even onder /sys/class/led (als ik me niet vergis) naar de leds.

[Verwijderd]

Thanks
Het log:

code:

jean@server:~$ tail -f /var/log/messages
Oct 20 11:40:59 server kernel: [1471820.182059] Total swap = 5922808kB
Oct 20 11:40:59 server kernel: [1471820.191383] 515456 pages RAM
Oct 20 11:40:59 server kernel: [1471820.191383] 9815 pages reserved
Oct 20 11:40:59 server kernel: [1471820.191383] 338081 pages shared
Oct 20 11:40:59 server kernel: [1471820.191383] 227120 pages non-shared
Oct 20 11:40:59 server kernel: [1471820.191383] SLUB: Unable to allocate memory on node -1 (gfp=0x20)
Oct 20 11:40:59 server kernel: [1471820.191383]   cache: kmalloc-256, object size: 256, buffer size: 256, default order: 0, min order: 0
Oct 20 11:40:59 server kernel: [1471820.191383]   node 0: slabs: 140, objs: 2240, free: 0
Oct 21 07:42:42 server rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="935" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Oct 22 07:53:31 server rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="935" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.

Ik wordt er niet veel wijzer van.

/sys/class/ bestaat wel maar geen map of file die led heet.

[H!GHGuY]

Verwijderd schreef op zaterdag 22 oktober 2011 @ 11:35:
Thanks
Het log:

code:

jean@server:~$ tail -f /var/log/messages
Oct 20 11:40:59 server kernel: [1471820.182059] Total swap = 5922808kB
Oct 20 11:40:59 server kernel: [1471820.191383] 515456 pages RAM
Oct 20 11:40:59 server kernel: [1471820.191383] 9815 pages reserved
Oct 20 11:40:59 server kernel: [1471820.191383] 338081 pages shared
Oct 20 11:40:59 server kernel: [1471820.191383] 227120 pages non-shared
Oct 20 11:40:59 server kernel: [1471820.191383] SLUB: Unable to allocate memory on node -1 (gfp=0x20)
Oct 20 11:40:59 server kernel: [1471820.191383]   cache: kmalloc-256, object size: 256, buffer size: 256, default order: 0, min order: 0
Oct 20 11:40:59 server kernel: [1471820.191383]   node 0: slabs: 140, objs: 2240, free: 0
Oct 21 07:42:42 server rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="935" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Oct 22 07:53:31 server rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="935" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.

Ik wordt er niet veel wijzer van.

/sys/class/ bestaat wel maar geen map of file die led heet.

die block_dump moet je even aan laten. Dan print hij in je kernel log welke blocks dirty worden en wanneer er naar de disk geschreven wordt. Je zou tussendoor even kunnen testen door

code:

touch ~/eenfile
sync
rm ~/eenfile
sync

te doen.

[The Eagle]

Je probleem is niet uniek, onder Windows heb je dit ook gewoon. Onder XP had ik het al en nu onder W7 ook. Heck, zelfs als ik mijn PC met een DOS floppy zou starten doet ie dat volgens mij (al is dat lang geleden )

ANyways, volgens mij heeft het te maken met het feit dat er gegevens van de HDD gevraagd worden. Dat kan fysieke data zijn (lees / schrijfacties), maar ook andere hardware uitlezingen. Denk aan SMART etc. Hoeft niet eens van het OS af te komen.
Maar da's vrij makkelijk te testen lijkt me: Boot je PC met een non-bootable floppy. Als je lampje dan nog steeds knippert hoef je je OS iig niet meer te verdenken

Is het je OS wel, dan is mijn eerste ingeving HDD monitoring door het OS, of simpelweg de swapfile. Maar die swapfile heb je zo uitgezet

[Verwijderd]

die block_dump moet je even aan laten. Dan print hij in je kernel log welke blocks dirty worden en wanneer er naar de disk geschreven wordt.

Ok, ik had hem na een minuut of 2 afgebroken omdat er niks bij leek te komen, ik zal hem zo een uurtje laten runnen.

Je zou tussendoor even kunnen testen door <snip> te doen.

Hm wat leert me die test dan? Maar ik ga hem even laten dumpen..

@The Eagle

Ik heb het op xp ook gehad en ik heb na wat zoekwerk dingen gevonden als indexing service / cdrom autorun etc. uitzetten die het tenslotte verhielpen, zo gewoon vind ik het dus niet, maar goed wie ben ik.
ps: floppy??

[The Eagle]

Floppy ja, zo'n ding dat ze ook wel een diskette noemen. Maar ik hoor het al, u is van het post-apocalyptische tijdperk

Anyway, het gaat er om dat je uitsluit dat het OS gebonden is. Mogelijk kun je in je BIOS even iets met bootvolgorde doen. Zolang ie maar blijft hangen en geen OS boot, en kijken of je hem dan nog ziet knipperen. Zo ja: dan ligt het dus niet aan linux, maar dieper

Met een floppy is dat verreweg het makkelijkste, non-bootable USB stick zou ook moeten lukken maar dat doe ik zelf eigenlijk nooit. Ik heb nog zeeen van floppy's liggen namelijk

[Steef]

Ben je in je zoektocht naar mount parameters deze al tegen gekomen:

commit=60

Uit de ext4 manpage:

commit=nrsec (*) Ext4 can be told to sync all its data and metadata
every 'nrsec' seconds. The default value is 5 seconds.
This means that if you lose your power, you will lose
as much as the latest 5 seconds of work (your
filesystem will not be damaged though, thanks to the
journaling). This default value (or any low value)
will hurt performance, but it's good for data-safety.
Setting it to 0 will have the same effect as leaving
it at the default (5 seconds).
Setting it to very large values will improve
performance.

Dit vertraagt de frequentie waarmee je filesysteem fysiek word bijgewerkt, het zou een "quick and dirty" fix voor je probleem kunnen zijn.

De echte vraag is natuurlijk: wat vraagt constant om schijf updates.

Mocht je er toegang tot hebben, je kunt het programma atop gebruiken om te bekijken welk proces schijf activiteit veroorzaakt.

atop -d toont schijf activiteit, als ik mij niet vergis.

[Verwijderd]

@The Eagle
Nee niet post-apocalyptisch, eerder pre. M'n eerste floppydrive was een Discovery Opus voor de zx-spectrum.
Je tip ga ik wel eens proberen, keertje wat proberen met bios boot opties, het is een server dus ik moet dan even een backupmachine uptodate maken.

@ThaRabbit
Ik heb ook geprobeerd journaling helemaal uit te zetten met hdparm, een van de oplossingen uit die thread, maar het hielp niet. atop kende ik nog niet, maar die laat net als iotop jdb2 zien wat weer op journaling lijkt te wijzen.
Maar dan nog, het ding flikkert 2 keer per seconde, dat is een veel hogere frequentie als dat jdb2 zich laat zien, een van de voorlopige conclusies uit de thread was ook dat je het op de een of andere manier niet kunt zien met de tools waarmee dat zou moeten kunnen. (wat weer misschien lijkt op wat The Eagle vertelt)

[stijnos1991]

De symptomen komen mij erg bekend voor. Ik draaide Ubuntu op een ma74gm-s2h met een AMD 1250LE processor en 1.5TB WD green schijf wat ook voor veel onnodige schijfactiviteit zorgde. Om de 5 seconden werd er 'iets' weggeschreven ondanks dat er geen applicaties draaiden. Mijn grootste probleem hiermee was dat de schijf nooit kon down-spinnen, iets wat je op een NAS wel graag ziet. jdb2 was de grote boosdoener. Probleem nooit opgelost...

[magistus]

mocht je niets zien in /var/log/mesages bij het aanzetten van block_dump, kijk dan eens in /var/log/kern.log. Onder Debian (en mogelijk dus ook onder Ubuntu welke een deriviate van Debian is) splitst zijn logmeldingen over verschillende logs, ipv Red Hat gebaseerde distro's waar vaak alles in /var/log/messages voorbij komt.

edit:
output van 'dmesg' zou natuurlijk ook moeten werken

[ Voor 9% gewijzigd door magistus op 24-10-2011 15:26 ]

[Verwijderd]

Met dmesg zie ik zowat alleen maar dingen over sda1.

80% van de regels zijn jdb2 entries:
[1668312.011302] jbd2/sda1-8(278): WRITE block 36767328 on sda1

Maar toen ik journaling uit had gezet met hdparm knipperde het ook.

Ik weet wel dat als ik straks meer tijd heb en een backup van dat ding heb draaien dat ik andere distro's ga proberen.

edit, dmesg output: http://jcremers.com/dmesg.txt

[ Voor 8% gewijzigd door Verwijderd op 24-10-2011 18:00 ]

[Steef]

Uit je dmesg output zou ik toch echt concluderen dat het journaling is die je in de weg zit. Je hebt de noatime etc al geprobeerd zag ik?

Al van iets heel banaals opgestart om te kijken of dat ook schijf activitieit veroorzaakt?
mini windows xp van hiren's boot cd ofzo

[Verwijderd]

Ik had journaling uitgezet met deze methode uit de bovengenoemde thread:
https://bugs.launchpad.ne...x/+bug/607560/comments/39
En ook gechecked nadien, het stond niet meer aan volgens genoemde methode.

Binnenkort ga ik de reserve pc up to date maken zodat die kan gaan serveren, dan kan ik gaan experimenteren met deze pc. Er staat zelfs nog een windows install in het grub menu.

noatime help niet nee.

[H!GHGuY]

Zoek even de 'dirtied' regels in dmesg. Die geven aan welk process de block heeft gedirtied.

[Verwijderd]

Daar zit vanalles tussen. Hier http://jcremers.com/dmesg.txt een dump van dmesg | grep dirtied

[H!GHGuY]

In de timestamps links zie je dat er tussenpozen van >5s in zitten. Niets wat dus echt regelmatig schrijft.
Mocht je nu ook nog even de WRITE regels ertussen kunnen hebben:

code:

dmesg | egrep 'dirtied|WRITE'

Maar ook daar verwacht ik niet dat er elke halve second data weggeschreven wordt.

Heb je de luistertest al eens geprobeerd? Hou je oor zo dicht bij de HD als mogelijk.

[Verwijderd]

Dit http://jcremers.com/dmesg.txt lijkt ook die > 5s te hebben.

Ik weet niet precies wat je bedoelt met luisteren maar de hd maakt kabaal ook doordat hij niet uit gaat staan, dat is een duidelijk te horen verschil.
Die pc draait al bijna een jaar zo, ik verwacht ieder moment dat die hd het een keer op gaat geven zo.

[H!GHGuY]

HD's ratelen als ze lezen/schrijven. Als je op de frequentie van de knipperende LED de HD niet hoort dan is het wsch iets anders.

Als je voor het leven van je HD vreest, dan draai je smartctl maar even.

[Verwijderd]

Sorry ik zie de reply nogal laat.

Dit http://jcremers.com/smartctl.txt is de output van

code:

sudo smartctl --all /dev/sda1

en voor zover ik begrijp ziet dat er goed uit, 'No errors logged'.

Dat stelt enigzins gerust. Ik hoor de hd niet op de frequentie van de LED nee, maar hij is wel hoorbaar en spint ook niet down.

[audiogek11]

Ik heb had hetzelfde met W7 x64, met de regelmaat van de klok knippert ie ongeveer om de seconde 1 keer, of 2x snel achter elkaar (lijkt bijna 1x).
Nou heb ik echt al allerlei "oplossingen" geprobeerd, van autorun uitschakelen tot 'windows dvd maker' uitschakelen tot register-edits en ga zo maar door ...maar niks werkte

Tot ik hier hetvolgende tegenkwam:

I'm appalled to see that "hard disk errors" or "indexing" is provided as the official Answer in this official MS site. That's nonsense; Windows is polling the CD/DVD drives and/or USB-based Card Readers that may be installed to a system, whether XP or 7 or what-have-you.

The "solution", which is of course not a good one at all, is to disable those devices in Device Manager. Now the LED pulsing will accurately reflect HDD access.

And why do we care about HDD access, vs. unplugging it (or duct-taping it as one blind man suggested)? We care because it is a useful tool to be able to observe when the HDD is busy, e.g. when startup is over, or a virus scan is complete, or what-have-you. It is also helpful, if you are paranoid about your SSD writes, to be alerted to activities which cause significant HDD (now SSD) access.

Why MS fails to address this is unknown, and will likely remain so. One mystery of many, such as their ridiculously aggressive Power Management features (especially in Windows 7) which have so frustrated users that they simply turn-off all such, and run the heck out of their PCs. Is this what you intended Mr. Gates?

Regarding disabling devices, when you realize you don't need your CD/DVD or Card Reader functions all that often anyway, you can set-up some batch files/shortcuts using DevCon commands to disable and re-enable these devices as you need them. I will leave the creation of devcon commands as an exercise for the reader...

Dus gewoon in apparaatbeheer je cd/dvd drive uitschakelen.
En nou is dit natuurlijk geen echte oplossing, maar voor mij werkt het. Die ene keer in de 2 maanden dat ik m'n dvd-drive gebruik zet ik 'm wel weer ff aan in apparaatbeheer.

Maar het belangrijkste is, dat we nu weten dat het geen onnodige ssd/hdd writes zijn waren

Het lijkt een probleem te zijn tussen Windows en sata cd/dvd-drives (die ik tot voor kort dus nog niet had)
Al is dit topic een jaar oud, ik hoop dat iemand hier nog wat aan heeft, want ik heb me de @!*#&!! gezocht

[RaZ]

Behalve dat het topic oud is, gaat het in NOS juist om een anders OS dan Windows. Er zal niemand dus iets aan hebben.

[audiogek11]

Damn...heb ik weer he....hopen dat'ie mag blijven staan voor de windows gebruikers, want ik kwam hier dus via google en het lijkt om hetzelfde probleem te gaan, maar blijkbaar heb ik in mn driftige zoektocht naar een oplossing wat te snel gelezen.

[Aardwolf]

Hey verrek, dat werkt echt. Ik vroeg me ook al tijden af waardoor het kon dat die LED zo als een diehard aan één stuk doorknipperde. Nu ff in apparaatbeheer uitgeschakeld en verhip, de LED komt in rust. Je zou er bijna van schrikken. haha

@ RaZ, je hebt wel gelijk, maar toch wel mooi deze post. Daar heb ik iig wel iets aan gehad, weet alleen niet of ik hem nu zo laat staan, gezien we hier de DVD brander nog wel af en toe gebruiken.