Before getting into the output here is my typical experience with SMART, there is what I call a "bad disk" with pending and uncorrectable sectors that cannot be reallocated.
It has caused a kernel panic and system crash repeatedly as we can see from the logs.
But SMART says it has "PASSED" its self assessment. SMART is still useful to me but it is more about looking at Current_Pending_Sector.
Any time I have had anything but 0 for that attribute it........
This is just trying to read 5GB off the drive with dd and the drive initially tested ok but shortly after I wondered why I was seeing 2MB/s read speeds. Notice the "current_pending_sector", anytime I've seen it at anything above 0 even with no other bad fields/attributes, it means the drive is bad.
ata1.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x0
ata1.00: irq_stat 0x40000008
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/00:00:........
This is something many people and especially businesses worry about, or at least they should. Before throwing away a hard drive, returning a hard drive, or especially Warrantying/RMAing it, you should wipe the drive.
Linux provides the "shred" and "dd" utlities which work quite well. It seems even a single pass is good enough but by default shred will do 3 passes.
Here's an example of using shred in Linux (I use a custom made distribution from........
This assumes that you've at least created the correct partition for your DRBD already.
Notice that I am "diskless", that's because either your DRBD partition doesn't exist/has been renamed (eg. sdb becomes sda when sdb dies and you reboot) or because that drive is really actually dead/gone.
*If you need to permanently change the partition/device for your resource be sure to edit /etc/drbd.conf on both hosts and reload the config.
(replace r0 with........
This happened during a RAID array check:
SMART says both drives pass the test, but I'm doing a long test on them and hopefully this is not a hardware error.
Apr 3 04:22:01 remote kernel: md: syncing RAID array md2
Apr 3 04:22:01 remote kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
Apr 3 04:22:01 remote kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
[27969.398749] sd 5:0:0:0: [sdb] 3907029168 512-byte hardware sectors (2000399 MB)
[27969.398749] sd 5:0:0:0: [sdb] Write Protect is off
[27969.398749] sd 5:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[27969.398749] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[27972.117543] ata6.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[27972.117543] ata6.00: irq_stat 0x48000000
[27972.117543] ata6.00: cmd 60/08:00:ff:7........
ERROR: sdb2/backup.r18 failed verification -- update retained.
This happened when Iwas rsyncing a dying hard drive, a lot of people seem to report this as an error with rsync itself but I don't think rsync is the issue at all.
I know the source hard drive was bad, it was having all kinds of timeout, seek, hardware ECC recovered and reset errors.
The only time something else could be the problem is if the data is being corrupted in transit, perhaps through........
This drive is clearly on the way out, the Kernel knows it but I'm surprised that SMART is not concerned. I didn't blame Seagate for their past issues until now. This hard drive has hardly been used and has not even been powered on for a year according to SMART.
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.11
Seagate Inventory/Firmware Check
I heard about this issue a long time ago but never looked into it. I figured I wasn't affected since my 500GB drives were running for so long. I've been using Seagate's since 2002 and to this day all of the drives I have are alive from Seagate.
*Update the bad news is that I realize one of my 500GB's is about to die, it's not even a year old, but is also not affected by the recall according to Seagate!