Vandaag heb ik hem wel 10x opnieuw opgestart en fsck geeft aan dat die clean is.
De laatste redmiddel is /home opnieuw te formateren, of heeft iemand anders nog een idee?
Afdrukvoorbeeld
Maar heeft fsck wel gechecked ?
Als hij alleen maar naar de filesystem-clean vlag in het superblock gekeken heeft , zegt dat niks.
Dat is de default, voor een clean filesystem. Pas na een x-aantal dagen of y aantal mounts (instelbaar met tune2fs, zichtbaar met dumpe2fs) wordt een filesystem alsnog gechecked ook wanneer het clean is.
Doe eens : fsck -f -V /dev/sda8
(-f : force, -V : verbose)
Hoe doe je de fsck: via single mode of een rescue cd ?
Laatst voor een klant soortgelijke problemen gehad ook met een 3ware 8006-2 en 2 wdc re schijven de controller en array waren allen goed gaven geen smart meldingen
zowel via hdparm als 3dm tool (centos machine).
Echter na rescue mode opstarten en de filesystem gecontroleerd kwamen er toch badsectors naar boven deze waren gefixed heb daarna nieuwe schijf erin gedaan zodat hij kon rebuilden paar uur later klaar de schijven allebei geswapped.
Zodat de klant voorzien was van een nieuwe set schijven had in raid 1.
Daarna heb ik om de fout op te sporen de oude defecte schijven los gecontroleerd met een tooltje van western digital om iig zeker te weten dat het niet software gerelateerd was.
Hierbij bleek dat er meerdere bad blocks waren welke niet zichtbaar waren voor je os direct en ook niet door de 3dm tool maar wel door het programma van western digital
echter de smart status bleef goed dus het probleem lag gewoon aan de schijven.
Heb ik nu gedaan.. zie de uitkomst:
Hopelijk gaat het nu weer goed, de laatste check was ook al een jaar geleden.Citaat:
fsck -f -V /dev/sda8
fsck 1.39 (29-May-2006)
[/sbin/fsck.ext3 (1) -- /home] fsck.ext3 -f /dev/sda8
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -24202470 +24202726
Fix<y>? yes
Free blocks count wrong for group #174 (26257, counted=26256).
Fix<y>? yes
Free blocks count wrong for group #230 (255, counted=250).
Fix<y>? yes
Free blocks count wrong for group #233 (178, counted=176).
Fix<y>? yes
Free blocks count wrong for group #404 (193, counted=194).
Fix<y>? yes
Free blocks count wrong for group #673 (2558, counted=2548).
Free blocks count wrong for group #738 (30778, counted=29804).
Fix<y>? yes
Free blocks count wrong for group #739 (31720, counted=31664).
Fix<y>? yes
Free blocks count wrong (12702885, counted=12701838).
Fix<y>? yes
Free inodes count wrong for group #174 (32747, counted=32746).
Fix<y>? yes
Free inodes count wrong for group #230 (32526, counted=32518).
Fix<y>? yes
Free inodes count wrong for group #673 (24808, counted=24807).
Fix<y>? yes
Free inodes count wrong for group #738 (32564, counted=32422).
Fix<y>? yes
Directories count wrong for group #738 (5, counted=4).
Fix<y>? yes
Free inodes count wrong (27390589, counted=27390437).
Fix<y>? yes
/home: ***** FILE SYSTEM WAS MODIFIED *****
/home: 495131/27885568 files (6.9% non-contiguous), 15166912/27868750 blocks
Iedereen bedankt voor het helpen!
De map waardoor /home in read-only ging kon nu verwijderd worden zonder problemen.
Achteraf had ik dit in 5 minuten kunnen fixen, dus alweer wat geleerd :)
-
ichosting ik heb het niet in single mode gedaan, de map /home is een aparte partition en dan heeft dat geen nut volgens mij omdat de fout in /home zat.
Zo te zien zijn de hdd's verder goed, maar ik zal ze vanaf nu extra gaan monitoren voor de zekerheid.