fsck help please

[Henry Yen]

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
   boots up.
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
health check.

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?