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

Re: What to do? Error:(Attempt to read block from filesystem resulted in short read) while doing inode scan.)



On Fri, Aug 30, 2002 at 11:58:49AM +0100, Ed W wrote:
> Pass 1: Checking inodes, block, and sizes
> Error reading block xxxxxxx (Attempt to read block from filesystem resulted
> in short read) while doing inode scan.
> 
> I don't recall the exact block numbers (seem to have misplaced my notes
> where I wrote them down...).  However, they were reproducible every time I
> ran fsck
> 
> So the question is how do I take this forward?  I assume that it means a
> dead sector?  Is there any way to find out which files occupy that sector so
> that I can be suspicious of their quality?  

This specific error means that you had a bad block inside your inode
table.  Depending on where in the inode table you had bad block, you
could have lost as many as 32 files.  (If you saw complaints about
directory entries pointing to deleted files, that would be
confirmation.)

> Can I mark the sector as bad and recover any of the data?  

You can mark the sector as bad by doing "e2fsck -c".  You can try to
see if the disk drive will remap the sector by doing a non-destructive
read/write badblocks check.  With e2fsck versions 1.26 or later, this
can be done by using the command "e2fsck -cc".  With older versions of
e2fsprogs, you'll need to run "badblocks -n" manually.  Note that this
can be dangerous!  If your disk is starting to die, more disk activity
can make things worse, not better.  I'd normally suggest that people
do a full disk-to-disk image backup before starting.

> The only hint I really have that something is wrong is my backup via tar
> always ends with:
> 
>           tar: Error exit delayed from previous errors
> 
> (As an aside is tar a satisfactory method of doing a full backup of an ext3
> filesystem?)

Under normal circumstances yes.  A much more paranoid way to do a disk
backup, which is what I recommend in these sorts of circumstances, is
to do a disk-to-disk image backup.  In order to do this you need a
disk partition at least as big as the one which you are backing up.
You then issue this command, while the filesystem is unmounted:

	dd if=/dev/hd_old_disk of=/dev/hd_backup_disk bs=1k conv=sync,noerror

If you don't have a spare disk, consider getting one.  Disk drives are
terribly cheap these days, and the data on the disk is generally worth
a factor of 10 or 100 more than purchasing a new disk might cost.
This is why sometimes people will simply replace a disk on a drop of
the hat as soon as they start seeing soft errors (i.e., warnings from
the disk that there were read errors that were correctable using ECC),
never mind the hard errors which you're clearly seeing here.  Their
time to dick around and figure out whether or not the errors on the
disk are stable or not, or to replace the disk and deal recovering
from backups, just simply isn't worth it.  It's often better to spend
the $100 or so for a new 80 gig drive, and just move on.

> Pointers and preferably notes as to what to be careful not to do would be
> really appreciated (this is a live system and I would rather not need to
> test my backups).

Good luck!!

						- Ted





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