Linux логи ошибок диска

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

If you have installed smartmontools, and enabled smartd then all log entries are available in /var/log/syslog:

grep "smartd" /var/log/syslog*

For /dev/sda

grep "smartd.*/dev/sda" /var/log/syslog*

An other example:

$ grep "smartd.*/dev.*failure" /var/log/syslog*

/var/log/syslog:May 14 10:46:58 sturm smartd[608]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 120 to 104
/var/log/syslog:May 14 10:46:58 sturm smartd[608]: Device: /dev/sdb [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 117 to 119
/var/log/syslog.1:May 13 05:30:33 sturm smartd[631]: Device: /dev/sdb [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 110 to 113
/var/log/syslog.1:May 13 11:19:26 sturm smartd[651]: Device: /dev/sdb [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 113 to 115
/var/log/syslog.1:May 13 11:49:26 sturm smartd[651]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 120 to 100
/var/log/syslog.1:May 13 11:49:26 sturm smartd[651]: Device: /dev/sdb [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 115 to 117
/var/log/syslog.1:May 13 15:49:27 sturm smartd[651]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 100 to 102
/var/log/syslog.1:May 13 19:49:26 sturm smartd[651]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 102 to 104
/var/log/syslog.1:May 14 10:16:58 sturm smartd[608]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 104 to 120

You must log in to answer this question.

Not the answer you’re looking for? Browse other questions tagged

.

From the smartctl man page:

The Attribute table printed out by smartctl also shows the «TYPE» of the Attribute. Attributes are one of two possible types: Pre-failure or Old age.
Pre-failure Attributes are ones which, if less than or equal to their threshold values, indicate pending disk failure. Old age, or usage Attributes, are
ones which indicate end-of-product life from old-age or normal aging and wearout, if the Attribute value is less than or equal to the threshold. Please
note: the fact that an Attribute is of type ‘Pre-fail’ does not mean that your disk is about to fail! It only has this meaning if the Attribute´s current
Normalized value is less than or equal to the threshold value.

If the Attribute´s current Normalized value is less than or equal to the threshold value, then the «WHEN_FAILED» column will display «FAILING_NOW». If
not, but the worst recorded value is less than or equal to the threshold value, then this column will display «In_the_past». If the «WHEN_FAILED» column
has no entry (indicated by a dash: ´-´) then this Attribute is OK now (not failing) and has also never failed in the past.

So according to the smartctl output section you have posted, your drive actually looks in good shape. However, that doesn’t necessarily mean that there is not another problem.

Unfortunately the Unhandled sense code message does mean that something went wrong, but the kernel doesn’t know what. You could try looking at the rest of the smartctl output to see if there is any thing wrong. There should be a part tha summarises the drive’s overall health. You can get it on its own with the -H option.

If the drive supports self testing, you can start one with:

smartctl -t long /dev/sda

This starts one in the background, so you will have to keep checking for results. If the drive is not mounted, you can add the -C option enable captive mode which should take less time. A short test is also possible, but less thorough.

It is also a good idea to check physical connectors etc to make sure nothing as come loose — its an easy fix if it has.

Update

Wikipedia has a good reference for smart attributes. Note that the ‘Better’ column refers to the raw values in rightmost column of the output and not the normalised value at the start. Here is the part on ‘Current Pending Sector’ mentioned by frostschutz:

Count of «unstable» sectors (waiting to be remapped, because of unrecoverable read errors). If an unstable sector is subsequently read successfully, the sector is remapped and this value is decreased. Read errors on a sector will not remap the sector immediately (since the correct value cannot be read and so the value to remap is not known, and also it might become readable later); instead, the drive firmware remembers that the sector needs to be remapped, and will remap it the next time it’s written. However some drives will not immediately remap such sectors when written; instead the drive will first attempt to write to the problem sector and if the write operation is successful then the sector will be marked good (in this case, the «Reallocation Event Count» (0xC4) will not be increased). This is a serious shortcoming, for if such a drive contains marginal sectors that consistently fail only after some time has passed following a successful write operation, then the drive will never remap these problem sectors.