fsck help please
blinux-mail at AegisInfoSys.com
Mon Sep 10 23:07:13 UTC 2012
uh-oh. this mound of errors could signal that your hard drive has been
damaged, and that there are bad (unreadable) spots now. Here's some
answers/guesses about your questions, followed by my recommendation
of what to do or try next...
1. Force-rewriting may be an effort to get the drive controller to
reallocate the failing block to a spare block. It may a last-ditch
attempt, in that fsck claims to just plain not be able to read that
block, so "please mister disk drive, you try it, and if you can
read it, please move it to another spot". It's not a matter of
embracing or fearing, it's rather fsck can't read some or all of
the block no matter what. That's obviously not good.
2. Clearing the inode clears the contents of the inode, which is
the information needed to find all of the blocks of the file to
which that inode belongs. Generally, fsck won't suggest clearing
an inode unless it thinks that it already doesn't belong to any
file; clearing it will then (eventually) free up the blocks that
were allocated to that inode. If the inode and its file pointer
have become incorrectly disconnected in fsck's mind, again, that's
obviously not good.
3. If fsck gives up on the filetype, it is again because it no longer
has enough information about what the file is (or used to be). It is
now just guessing. Yes, those affected files can mess up your system
if the filetype is changed or assigned. Generally, if the complaint
is that the file is/was a "socket", it's more likely than not
these are temporary in nature, and you can go ahead and let fsck
make its best guess. Otherwise, you might just write down what fsck
thinks of these, decline its offer to change/assign the filetype,
and then do this action yourself, after your linux system successfully
4. Yes, the "dash-a" option tells fsck to go ahead and attempt to fix
filesystem errors to the extent there's no reasonable option to
do something else, as well as minimizing the likelyhood of making
something bad even worse. For most true filesystem errors, this
is usually good enough; fsck will abort if there's something truly
horrible, or if it can't be somewhat confident that fixing one
problem won't whack something else. Some versions of fsck also have
a "dash-n" option, which is the opposite of "dash-a".
HOWEVER: if your hard drive has gone bad, you mustn't do anything else
with it except recover to a separate drive (hopefully one that's known
to be good). Hard drives, once they suffer physical damage, will generally
deteriorate rapidly. So, my advice would be to boot to a live CD, and
run a command that will simply do a check of the drive's physical health.
At the least, just try reading every block of the entire disk -- if there
is but one error (except perhaps at the extreme tail end), you'd better
copy everything off to another disk, and replace the failing one.
There are undoubtedly several decent choices to this, but I'm not
particularly familiar with the snazzy ones (and, those are unlikely
to be usable without sighted assistance). Common command-line programs
would be the "badblocks" program, as well as a simple "dd" command
(along with its two offspring, "ddrescue" and "dd-rescue"). The
"dd" command would be simply: "dd if=/dev/sda of=/dev/null" --
note that if you type this wrong, you could instead WIPE YOUR ENTIRE
DRIVE instead. Sighted-assistance could probably use the systemrescue CD
(www.sysresccd.org), although you must first pass the basic drive
On Mon, Sep 10, 2012 at 14:32:23PM -0400, aerospace1028 at hotmail.com wrote:
> >> fsck /dev/sda4
> [ 596.198487] Buffer I/O error on device sda4, logical block 8394655
> Error reading block 107933, (Attempt to read block from filesystem
> resulted in short read) while getting next inode from scan. Ignore
> First after the "Error reading block ..." lines when it prompts "force
> rewrite" what is it rewriting? Is this to be embraced or feared?
> Second, on the deleted/unused inode prompts, What is it clearing (the
> inode itself, or the sign pointing to the inode)?
> On the entries about the incorrect filetype, I presume it's actually
> safe to just trust fsck on this one? Just double-checking so I don't
> put my system into an unrecoverable state.
> Lastly, would the proper way of invoking fsck on the live-CD be
> fsck -a /dev/sda4
> If I'm reading the manual correctly, that will autofix the "safe"
> options, correct?
More information about the Blinux-list