filesystem problem

Hello,

I just had to run e2fsck on my ext3 filesystem because there was some serious error. e2fsck showed me the following: Inode 324401 has illegal block(s) [...] Illegal block #-1 ([...]) in inode 324401. CLEARED. What does 'CLEARED' mean? Does it mean that some data is lost or modified? And if this is the case, how can I detect which data is damaged?

It means he removed the blocks from the list of block used by the inode.

You have the i-node that point to a file or directory. Get the file and check it.

He removed the blocks (plural) or the block (singular)?

And how do I know to which file or directory the i-node points to?

Singular and then plural in that order. Does it matter?

You go look. Problem?

Yes, problem. Where does one look? How does one look? Pretty much everyone knows about 'ls', but that works on filenames: how does one determine which filename corresponds to i-node number 324401?

Apparently this will work: 'find / -inum 324401 -print 2>/dev/null'

You look in the place where you are interested in looking, which is your filesystem. How do you look? Using your eyes to obeserve the output of such diagnostic tools as you may care to use.

ls works fine, but is not the choice I would make. No, ls does not 'work on filenames'.

ls -i -R grep -w 324401

would do fine.

You look.

So would dozens of other lookings. Is it worth remarking on?

I'd say much more so than your posting stupid comments like

No information, just a patronising rant. As usual. When you do offer info, it's typically a couple of lines swamped by your childish chest-beating. Blow it out of your arse, Breuer. To do so you may need to get your head out of the way first. You're not even amusing any more.

This is CORRECT! I am pointing out to him that he KNOWS where to look! Why do you allow him to get away with stupid patronising comments like 'where do I look'?

This is CORRECT!

Are you an idiot, crazy, or all three? Are you incapable of grasping the idea that the information is IN HIS OWN HEAD and all he need do is tear the plank out of in front of his eyes and see it! He knows perfectly well both where to look and what to look with. He even mentioned the latter, and he certainly knew the former.

You are a fat headed idiot. DO I bother to tell you about it? Yes. Say thanks. As to the 'typically a couple of lines', I gave him the exact line he needed to use, using his own suggested utility. Why he could not use the man page for the utility he sugggested to do that for him is between him and his god, but I gave it to him all the same, even though he needed not to have it given to him, but instead to be told that he KNOWS, so that he could go ahead and generate the information himself, instead of hiding behind his belief that he didn't know.

Have you any rational explanation of why you give huge negative weighting to a couple of lines telling him to look within himself, and tiny positive weighting to a single line giving him the exact solution? Prejudice! That's what! Idiocy, pure paranoid, self-important arrogant pompous inferiority-complex driven paranoia.

Cut it out.

Get your obviously numb skull back into school, wehere it clearly belongs, until you figure out that there are no secrets in the world, only things waiting for YOU to discover.

Calm down.

Now then, you've run into a subtle fallacy here. Just because someone talks about a task, and mentions a tool capable of performing that task, doesn't mean they *know that it can perform that task*. I know it seems to you like they should, but here's an analogy:

A man comes to you and says 'I need to twist a flat-head screw, but all I have is this Phillips-head screwdriver.' You notice that the screwdriver is actually a two-in-one device; pull the top part out, stick it back in the other way round, and it reveals a flat-head end.

So you tell him 'You've already got the tool you need.' Do you see why he fails to understand?

Handing him a separate flat-head screwdriver is OK. Telling him that the top is reversible is also OK. Telling him that he should read the screwdriver's printed instructions more carefully is *also* OK.

The reason I didn't read 'man ls' is that, when the task at hand is searching for a file whose directory is unknown, I think of 'find' first. I did read 'man find'.

'ls' is capable of the task, in the same sense that a butter knife is capable of picking up peas. It's not the ideal tool, though; your suggested command should really be tweaked to

ls -i -R -1 / 2>/dev/null grep -w 324401

which is probably less efficient than 'find'. Also, in theory, it could pick up false positives (i.e. any file whose *name* is '324401'.

NO. Understanding should follow immediately.

What I believe should happen at this point is that he should reexamine his beliefs, looking for holes in his internal logic that could have lead to a false conclusion. The reason why he should do that is that he has now been given forcefully expressed ostensibly factual information that contradicts derived (and therefore weakly held) information in his world view. Therefore he must examine how he arrived at his belief, looking for mistakes in his internal logic.

None of these things is necessary, and indeed none of them is deducible by me (in the general case) as being the false step that he has taken. Any one of those or some other mistake could be the cause of his misaprehension. I believe it is up to HIM to fix his internal logic, not me, and oftenI will not presume to guess at it.

I would imagine that the mistake really is 'a philips screwdriver is not also a flathead screwdriver'. As you note, it can be. Perhaps he could indeed be taught that by reading the instructions. But maybe he knows there is a religious proscription against dual-use of screwdrivers, and his screwdriver is marked kosher by the local screwdriver deacon, so he assumes that it cannot be dual-use. We don't know.

It is ingenious. I did not know that find had an option for inodes. It would have been low on my list of tools to investigate. My first stop wold have been 'debugfs', which I can almost bet can locate a file by inode. Then I would have looked at ls, since it is well known that ls can show the inode number of a file, and one can list all files and then pick out the one one wants with grep. Then I might look at mc, since I am sure it can sort and filter by inode. I might have looked at find, but by now it is irrelevant, since its functionality is already subsumed in what I've already mentioned.

Those improvements are fair enough (the -1 is not necessary since it goes to a pipe, not a tty, no?). Sending errors to /dev/null is a good idea, but would have to be done with find too. If there is a file whose name is 324401, then he deserves to lose.

Thank you for your comments, and I will incorporate them in my next pea soup.

Most people react rather poorly to 'no, you're wrong' in the absence of even a slight hint as to what specific thing they've got wrong. Then again, you don't seem to care, so I'll just keep pointing it out from time to time to be annoying.