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@xxxxxxxxxxx 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? _______________________________________________ Blinux-list mailing list Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list