[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Block read "resulted in short read" when dumping root fs, but all else is well



[This message has also been posted to linux.debian.user.]
In article <6Ejdu-5JD-9@gated-at.bofh.it>, Marcin Owsiany wrote:
>  I get the following
> error when dumping the root partition:
>
> [...]
>|   DUMP: Dumping volume 1 on /srv/backup/2006-07-26_Wed_level_3/_001
>|   DUMP: Volume 1 started with block 1 at: Wed Jul 26 06:25:08 2006
>|   DUMP: dumping (Pass III) [directories]
>| /dev/mapper/lv-pv: Attempt to read block from filesystem resulted in short read while reading inode #2
>
> However my filesystem seems OK. I haven't run fsck on it yet, but the fact that
> the next dump (on the subsequent day) runs just fine, suggests that this is not
> an error in the filesystem.

I suspect hardware.  Something's barely working, and when temperature,
vibration, and unlucky bit patterns line up against it, it fails.
People think of hardware as either working or not, but the reality
is noise and poor signal integrity.  Hardware needs operating margin
to be reliable, and typical PC motherboards don't have much.
Then people do silly things and make it worse.  The "Ultra DMA 133"
interface was designed for an eighteen inch cable.  That's why retail-
packaged drives come with them, so you won't buy a longer one
from a clueless/unscrupulous retailer and the manufacturer won't get
trouble calls about it.  If you use a twenty
four inch cable you may get lucky for a while.

I had a system that got disk errors during backup.  Replaced
drives and controllers, no change and they all work fine in other
motherboards.  Turns out the motherboard is defective, gets
"DMA timeouts" and other errors with any PCI ATA controller
in any slot.  Moved the drives to the second motherboard ATA
channel to get by till I can replace the motherboard;
this box doesn't really need a CD drive anyway.


Cameron



Reply to: