# ext4 Root Partition mit Fehlern

## CaptainHero

In letzter Zeit kommt häufiger die Meldung (ca. bei jedem dritten Bootvorgang), dass meine Root Partition ein fehlerhaftes Dateisystem enthalte und repariert werden müsse.

Nach dem Neustart läuft alles prima durch und ich habe auch sonst keinen Datenverlust zu beklagen und das System fährt auch immer sauber runter.

Dateisystem ist ext4. Das ganze passiert mit gentoo-sources 2.6.31.x bis 2.6.32.x

Es ist immer nur die Root Partition betroffen, habe noch zwei andere ext4 Partitionen, eine davon auf der selben Festplatte. 

```
smartctl --all -d ata /dev/sda3
```

 gibt:

```
smartctl version 5.38 [x86_64-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen

Home page is http://smartmontools.sourceforge.net/                          

=== START OF INFORMATION SECTION ===

Device Model:     SAMSUNG HD250HJ   

Serial Number:    S0URJDWQ611981    

Firmware Version: FH100-06          

User Capacity:    250.059.350.016 bytes

Device is:        In smartctl database [for details use: -P show]

ATA Version is:   8                                              

ATA Standard is:  ATA-8-ACS revision 3b                          

Local Time is:    Wed Dec 30 19:04:28 2009 CET                   

==> WARNING: May need -F samsung or -F samsung2 enabled; see manual for details.

SMART support is: Available - device has SMART capability.

SMART support is: Enabled                                 

=== START OF READ SMART DATA SECTION ===

SMART overall-health self-assessment test result: PASSED

General SMART Values:

Offline data collection status:  (0x02) Offline data collection activity

                                        was completed without error.    

                                        Auto Offline Data Collection: Disabled.

Self-test execution status:      (   0) The previous self-test routine completed

                                        without error or no self-test has ever  

                                        been run.                               

Total time to complete Offline                                                  

data collection:                 (3741) seconds.                                

Offline data collection                                                         

capabilities:                    (0x5b) SMART execute Offline immediate.        

                                        Auto Offline data collection on/off support.

                                        Suspend Offline collection upon new         

                                        command.                                    

                                        Offline surface scan supported.             

                                        Self-test supported.                        

                                        No Conveyance Self-test supported.          

                                        Selective Self-test supported.              

SMART capabilities:            (0x0003) Saves SMART data before entering            

                                        power-saving mode.                          

                                        Supports SMART auto save timer.             

Error logging capability:        (0x01) Error logging supported.                    

                                        General Purpose Logging supported.          

Short self-test routine                                                             

recommended polling time:        (   2) minutes.                                    

Extended self-test routine                                                          

recommended polling time:        (  63) minutes.                                    

SCT capabilities:              (0x003f) SCT Status supported.                       

                                        SCT Feature Control supported.              

                                        SCT Data Table supported.                   

SMART Attributes Data Structure revision number: 16

Vendor Specific SMART Attributes with Thresholds:  

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE

  1 Raw_Read_Error_Rate     0x000f   100   100   051    Pre-fail  Always       -       1        

  3 Spin_Up_Time            0x0007   253   253   025    Pre-fail  Always       -       4416     

  4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       1183     

  5 Reallocated_Sector_Ct   0x0033   253   253   010    Pre-fail  Always       -       0        

  7 Seek_Error_Rate         0x000f   253   253   051    Pre-fail  Always       -       0        

  8 Seek_Time_Performance   0x0025   253   253   015    Pre-fail  Offline      -       0        

  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       7606     

 10 Spin_Retry_Count        0x0033   253   253   051    Pre-fail  Always       -       0        

 11 Calibration_Retry_Count 0x0012   253   253   000    Old_age   Always       -       0        

 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       629      

 13 Read_Soft_Error_Rate    0x000e   100   100   000    Old_age   Always       -       111381   

184 Unknown_Attribute       0x0033   253   253   099    Pre-fail  Always       -       0        

187 Reported_Uncorrect      0x0032   253   253   000    Old_age   Always       -       0        

188 Unknown_Attribute       0x0032   253   253   000    Old_age   Always       -       0        

190 Airflow_Temperature_Cel 0x0022   193   112   000    Old_age   Always       -       15 (Lifetime Min/Max 1/42)

194 Temperature_Celsius     0x0022   184   112   000    Old_age   Always       -       18 (Lifetime Min/Max 1/42)

195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       111381                    

196 Reallocated_Event_Count 0x0032   253   253   000    Old_age   Always       -       0                         

197 Current_Pending_Sector  0x0012   253   253   000    Old_age   Always       -       0                         

198 Offline_Uncorrectable   0x0030   253   253   000    Old_age   Offline      -       0                         

199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0                         

200 Multi_Zone_Error_Rate   0x000a   253   100   000    Old_age   Always       -       0

201 Soft_Read_Error_Rate    0x000a   253   100   000    Old_age   Always       -       0

202 TA_Increase_Count       0x0032   253   253   000    Old_age   Always       -       0

SMART Error Log Version: 1

No Errors Logged

SMART Self-test log structure revision number 1

No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective Self-Test Log Data Structure Revision Number (0) should be 1

SMART Selective self-test log data structure revision number 0

Warning: ATA Specification requires selective self-test log data structure revision number = 1

 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS

    1        0        0  Not_testing

    2        0        0  Not_testing

    3        0        0  Not_testing

    4        0        0  Not_testing

    5        0        0  Not_testing

Selective self-test flags (0x0):

  After scanning selected spans, do NOT read-scan remainder of disk.

If Selective self-test is pending on power-up, resume after 0 minute delay.
```

Ich wüsste jetzt auch gar nicht, wo ich eventuelle Dateisystem logs anschauen könnte, bzw. bin auf dem Gebiet sowieso kein Experte, deshalb wäre ich für jede Hilfe dankbar.

Die Festplatte ist ungefähr 3 1/2 Jahre alt.

----------

## kernelOfTruth

also das sieht jetzt den Smart-werten zu beurteilen nach nicht nach einem Hardware-Problem aus   :Confused: 

du hast noch nie einen Smart-test laufen lassen ?

was für mount-optionen verwendest du denn?

also ich würd auf Nummer sicher gehen und sie mit folgenden mounten:

rw,noatime,nodiratime,commit=600,barrier=1,data=ordered

<-- das allerdings erst ab 2.6.32.2, da mit 2.6.32.1 oder .2 einige Probleme mit ext4 Daten- und Performance-technischer Art behoben wurden

selbst damit ist die Platte noch angenehm schnell genug für meine Verhältnisse (sie liest schnell genug und schreibt bzw. löscht schnell genug)

mach am besten ein Daten-Backup und verwende für die Partitionen auf anderen Platten ein anderes Dateisystem (z.B. ext3 oder reiserfs), das recht erprobt ist (just in case)

danach kannst du dann auch ein conveyance, offline, long, etc. smart-test durchlaufen lassen und mal schauen was sich tut

gibt es irgendwelche "error", "general protection" oder "BUG" Meldungen in /var/log/kern.log ?

cat /var/log/kern.log | grep BUG

cat /var/log/kern.log | grep segf

cat /var/log/kern.log | grep general

bzw. gibt es ab und zu Fehler-Meldungen in dmesg ?

----------

## Klaus Meier

Ich hatte auch mal eine Samsung, die sich langsam aufgelöst hat. Ok, jetzt bitte keine Diskussion über Marke, das hatten wir schon oft genug. Aber von der Zeit her passt es da rein, wo es mit Samsung Probleme ohne Ende gab.

Symptome bei mir: Daten defekt. Platte neu formatiert, ging 2 Tage gut und dann ging das Gleiche wieder von vorne los. Würde zusehen, dass ich die Daten erst mal woanders drauf bekomme, dann kannst es ja noch mal probieren, eventuell mit dem Tool von Samsung low level formatieren. Wenns dann geht, ok, wenn nicht, wovon ich ausgehe, Tonne.

P.S.: Zur Zeit habe ich wieder eine Samsung, die scheinbar keine Probleme macht.

----------

## mv

 *kernelOfTruth wrote:*   

> rw,noatime,nodiratime,commit=600,barrier=1,data=ordered

 

nodiratime ist nicht nötig, da von noatime impliziert. Von commit=600 würde ich die Finger lassen, aber das muss jeder selbst entscheiden.

Edit: Die wichtige Option journal_checksum fehlt in dieser Auflistung (und data=ordered sowie barrier=1 sollte default sein).

Zum eigentlichen Problem: Ich hatte mit baselayout1-* das Problem, dass die Root-Partition manchmal nicht richtig ge'umounted wurde; mit openrc ist das dann verschwunden. Außerdem kann es passieren, dass der Rechner beim Herunterfahren der Platte den Strom abstellt, bevor diese ihren internen Cache geleert hat - passiert bei meinem Laptop regelmäßig, bei jedem 2.-3. Boot. Auf einen Plattendefekt würde ich nicht tippen: Dass der Minimalst-Filesystemcheck beim normalen mounten (also nicht der, der von einem "echten" fsck stammt) auf Fehler stößt, die von etwas anderem herrühren als einem mangelnden Schreiben beim Herunterfahren, ist extrem unwahrscheinlich - da müsste die Platte schon total hinüber sein, und das würde sich auch anderweitig bemerkbar machen.

----------

## CaptainHero

Danke schonmal für die Antworten!

Also:

```
sudo cat /var/log/kern.log | grep general

Dec 15 22:44:25 Imbert kernel: [  369.008294] qtconfig[7749] general protection ip:7fd8892214d0 sp:7fffa5b48808 error:0 in libQtGui.so.4.6.0[7fd888e99000+922000]

Dec 15 23:11:00 Imbert kernel: [  282.910303] qtconfig[4648] general protection ip:7f367ac8e4d0 sp:7fff80c05f28 error:0 in libQtGui.so.4.6.0[7f367a906000+922000]
```

```
sudo cat /var/log/kern.log | grep segf

Nov 30 18:55:49 Imbert kernel: [11090.941544] bibletime[18063]: segfault at 10 ip 0000000000570b8a sp 00007fffa41c2820 error 4 in bibletime[400000+236000]      

Nov 30 19:00:47 Imbert kernel: [11388.917482] bibletime[18695]: segfault at 2c ip 0000000000570cc9 sp 00007fff0ce75f70 error 4 in bibletime[400000+236000]      

Dec  2 16:44:19 Imbert kernel: [11419.017348] kio_thumbnail[12669]: segfault at 7fc000001e3a ip 00007fc000001e3a sp 00007fc087196528 error 14 in SYSV00000000 (deleted)[7fc04c3b3000+71000]                                                     

Dec  2 16:49:54 Imbert kernel: [11754.512728] kio_thumbnail[1475]: segfault at 1933510 ip 0000000001933510 sp 00007fc087196528 error 15                         

Dec  2 16:55:03 Imbert kernel: [12063.058891] kio_thumbnail[13638]: segfault at 0 ip 00007fc098594dfc sp 00007fffd0535d30 error 6 in libQtGui.so.4.5.3[7fc0982cf000+866000]                                                                     

Dec  2 17:02:50 Imbert kernel: [12530.538794] kio_thumbnail[14871]: segfault at 0 ip (null) sp 00007fc04dc38d08 error 14 in kdeinit4 (deleted)[400000+b000]     

Dec  2 17:02:50 Imbert kernel: [12530.548107] kio_thumbnail[14882]: segfault at 0 ip (null) sp 00007fc05cd86d58 error 14 in kdeinit4 (deleted)[400000+b000]     

Dec  2 17:45:49 Imbert kernel: [15108.975437] kio_thumbnail[20613]: segfault at 0 ip 00007fc098594dfc sp 00007fffd0535c20 error 6 in libQtGui.so.4.5.3[7fc0982cf000+866000]                                                                     

Dec  6 15:47:22 Imbert kernel: [ 5655.571232] nepomukservices[30371]: segfault at 20156f0 ip 00000000020156f0 sp 00007f23a32b8528 error 15                      

Dec  7 18:51:27 Imbert kernel: [14516.943874] kio_thumbnail[23626]: segfault at 0 ip 00007f02c5b4167a sp 00007fff6cfa29b0 error 4 in libQtGui.so.4.5.3[7f02c555c000+866000]                                                                     

Dec 12 00:37:14 Imbert kernel: [ 1003.850366] kio_thumbnail[5172]: segfault at 0 ip (null) sp 00007fa913993538 error 14 in kdeinit4[400000+b000]                

Dec 14 05:48:33 Imbert kernel: [11421.001397] kio_thumbnail[25469]: segfault at 3a5dc00 ip 0000000003a5dc00 sp 00007f22b14fa538 error 15

Dec 15 09:38:56 Imbert kernel: [33384.021890] kio_thumbnail[29336]: segfault at 18ef500 ip 00000000018ef500 sp 00007fa080a7c538 error 15

Dec 15 09:40:20 Imbert kernel: [33467.854153] kio_thumbnail[29354]: segfault at 0 ip (null) sp 00007fa080a7c538 error 14 in kdeinit4[400000+b000]

Dec 15 22:41:58 Imbert kernel: [  222.057488] qtconfig[4845]: segfault at 172d090 ip 00007ff38c57aa01 sp 00007fff0931dd60 error 4 in libQtGui.so.4.6.0[7ff38c331000+922000]

Dec 15 22:48:40 Imbert kernel: [  624.591168] qtconfig[8007]: segfault at 0 ip 00007eff4c0b94d0 sp 00007fffda965bf8 error 4 in libQtGui.so.4.6.0[7eff4bd31000+922000]

Dec 21 19:44:56 Imbert kernel: [20430.924288] kio_thumbnail[15060]: segfault at 298df40 ip 000000000298df40 sp 00007f3b355cbd68 error 15

Dec 21 19:44:56 Imbert kernel: [20430.924335] kio_thumbnail[14886]: segfault at 0 ip (null) sp 00007f3b4579a018 error 14 in kdeinit4[400000+b000]

Dec 24 18:35:14 Imbert kernel: [19265.920204] kio_thumbnail[18945]: segfault at 0 ip (null) sp 00007f5f079b2478 error 14 in kdeinit4[400000+b000]

Dec 27 07:53:09 Imbert kernel: [43024.962086] normalize[25016]: segfault at 1 ip 0000000000409585 sp 00007fff8a693d50 error 6 in normalize[400000+f000]

Dec 27 07:55:15 Imbert kernel: [43150.286686] normalize[25120]: segfault at 1 ip 0000000000409585 sp 00007fff952a1d50 error 6 in normalize[400000+f000]

Dec 27 09:21:48 Imbert kernel: [48343.676236] normalize[29962]: segfault at 1 ip 0000000000409585 sp 00007fff688afa70 error 6 in normalize[400000+f000]

Dec 27 09:33:31 Imbert kernel: [49046.262441] normalize[30574]: segfault at 1 ip 0000000000409585 sp 00007fffd94f0320 error 6 in normalize[400000+f000]

Dec 30 00:52:07 Imbert kernel: [35972.747457] kio_thumbnail[15729]: segfault at 0 ip (null) sp 00007f1503dd6cd8 error 14 in kdeinit4[400000+b000]

Dec 30 00:56:27 Imbert kernel: [36232.505402] kio_thumbnail[15990]: segfault at 90 ip 00007f153a8b27c9 sp 00007fff404ca2d0 error 4 in libQtCore.so.4.6.0[7f153a83e000+274000]
```

```
cat /etc/fstab

# /etc/fstab: static file system information.

#

# noatime turns off atimes for increased performance (atimes normally aren't

# needed; notail increases performance of ReiserFS (at the expense of storage

# efficiency).  It's safe to drop the noatime options if you want and to

# switch between notail / tail freely.

#

# The root filesystem should have a pass number of either 0 or 1.

# All other filesystems should have a pass number of 0 or greater than 1.

#

# See the manpage fstab(5) for more information.

#

# <fs>                  <mountpoint>    <type>          <opts>          <dump/pass>

# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.

/dev/sda2               /boot           ext2            noauto,noatime  1 2

/dev/sda3               /               ext4            noatime         0 1

/dev/sda5               none            swap            sw              0 0

/dev/sdb1               /home           ext4            defaults,noatime        0 2

/dev/sda6               /home/rw/Musik  ext4            defaults,noatime        0 2

/dev/cdrom              /mnt/cdrom      auto            noauto,user     0 0

#/dev/fd0               /mnt/floppy     auto            noauto          0 0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for

# POSIX shared memory (shm_open, shm_unlink).

# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will

#  use almost no memory if not populated with files)

shm                     /dev/shm        tmpfs           nodev,nosuid,noexec    0 0

```

----------

## kernelOfTruth

 *CaptainHero wrote:*   

> Danke schonmal für die Antworten!
> 
> Also:
> 
> [snip]
> ...

 

also general protection und segfault Kandidaten scheinen die üblichen Verdächtigen Opfer zu sein, die durch den hardened Compiler bzw. pie und d_fortify_source=2 leichter crashen ...

verhalten sich bei dir die Programme irgendwie auffällig im Sinne von unvorhergesehenen Abstürzen, dass die grafische Oberfläche einfriert, Teile davon nicht mehr gehen, es zu Datenverlust kommt ? (hast du ja eigentlich schon ausgeschlossen)

D mount-Optionen sind soweit auch im normalen Bereich

bestätigt: commit=600 sollte nur angewendet werden, wenn du weist, dass dadurch Änderungen im Log nur noch alle 10 Minuten geschrieben werden und du das für notwendig bzw. erstrebenswert hälst  ... also lass es mal weg - wenn du mit dem Gedanken spielst es hinzuzufügen ...

----------

## schachti

 *mv wrote:*   

> Edit: Die wichtige Option journal_checksum fehlt in dieser Auflistung

 

Ich habe leider wenig Infos dazu gefunden, warum die wichtig ist - aus Performance- oder aus Sicherheitsgründen? Die Beschreibung in der man page von mount hört sich so an, als ob sie das Dateisystem etwas robuster macht...

----------

## Klaus Meier

 *kernelOfTruth wrote:*   

> also general protection und segfault Kandidaten scheinen die üblichen Verdächtigen Opfer zu sein, die durch den hardened Compiler bzw. pie und d_fortify_source=2 leichter crashen ...

 

Oder einfach Daten kaputt wegen Platte?

----------

## CaptainHero

Ich habe jetzt mal journal_checksum und rw für die Root Partition hinzugefügt. Seit dem ein Mal problemlos neu gebootet, aber wie gesagt, das Ganze trat eher unregelmäßig auf.

Nach dem, was ich über die journal_checksum Optionen gegoogelt habe, lohnt es sich wahrscheinlich schon es für jede ext4 Partition zu aktivieren, oder nicht?

 *Quote:*   

> verhalten sich bei dir die Programme irgendwie auffällig im Sinne von unvorhergesehenen Abstürzen, dass die grafische Oberfläche einfriert, Teile davon nicht mehr gehen, es zu Datenverlust kommt ?

 

Datenverlust keinen, nein, aber jetzt wo ich drüber nachdenke fällt mir ein, dass sich vor einiger Zeit kio_thumbnails mal 50 % meines RAM ( = 2 GB ) gönnte und das System komplett lahm legte, worauf nur ein logout / login half.  Das ist meines Wissens nach ein alter KDE Bug. Kam bei mir ein Mal vor. Das beschriebene Verhalten würde ja auch zu den von mir geposteten segfaults passen.

Ich werde das Verhalten mal weiter beobachten und die entsprechenden Tests laufen lassen.

Wünsche allen einen Guten Rutsch ins neue Jahr!

----------

## kernelOfTruth

 *Klaus Meier wrote:*   

>  *kernelOfTruth wrote:*   also general protection und segfault Kandidaten scheinen die üblichen Verdächtigen Opfer zu sein, die durch den hardened Compiler bzw. pie und d_fortify_source=2 leichter crashen ... 
> 
> Oder einfach Daten kaputt wegen Platte?

 

naja, dann wär bei mir aber EXTREM VIEL KAPUTT   :Wink: 

auszuschließen ist es jedenfalls nicht   :Idea: 

----------

## kernelOfTruth

 *CaptainHero wrote:*   

> Ich habe jetzt mal journal_checksum und rw für die Root Partition hinzugefügt. Seit dem ein Mal problemlos neu gebootet, aber wie gesagt, das Ganze trat eher unregelmäßig auf.
> 
> Nach dem, was ich über die journal_checksum Optionen gegoogelt habe, lohnt es sich wahrscheinlich schon es für jede ext4 Partition zu aktivieren, oder nicht?
> 
>  *Quote:*   verhalten sich bei dir die Programme irgendwie auffällig im Sinne von unvorhergesehenen Abstürzen, dass die grafische Oberfläche einfriert, Teile davon nicht mehr gehen, es zu Datenverlust kommt ? 
> ...

 

tu das, ich glaub nämlich auch nicht so ganz an ein Hardware-Problem - man wird aber öfters gerne eines anderen belehrt 

wie bereits geschrieben und mehrmals erwähnt ist es jedenfalls nicht wenig sinnvoll deine Daten auf eine andere Platte zu sichern (evtl. mit einem anderen Dateisystem[-Format]) um wirklich eine gewisse Sicherheit zu haben

 *CaptainHero wrote:*   

> 
> 
> Wünsche allen einen Guten Rutsch ins neue Jahr!

 

Danke  :Smile:  & gleichfalls

----------

