From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kuba Ober Subject: Re: A couple of questions Date: Fri, 17 May 2002 11:04:33 -0400 Message-ID: <200205171104.33045.kuba@mareimbrium.org> References: <200205161723.42672.kuba@mareimbrium.org> <20020516214419.GE15774@schmorp.de> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: list-help: list-unsubscribe: list-post: In-Reply-To: <20020516214419.GE15774@schmorp.de> List-Id: Content-Type: text/plain; charset="us-ascii" To: " ( Marc A. Lehmann )" Cc: reiserfs-list@namesys.com > > What I'm thinking of is this: > > to the user, which most users w/o intimate filesystem knowledge won't be > > able to answer at all? > > Unix traditionally wasn't aimed at the point-and-click users without > knowledge. Yep. But the thing is that either fsck can restore the data or not. There's no way in between. What more can unix-poweruser do about recovering a filesystem, other than running a disk editor (say a reiserfs-customized version of norton disk editor, which used to be a good thing for hand recovery of fat fs before it became crap) ? What kinds of questions can fsck really ask without having to present user with a lot of intricate data, which is better visualized graphically or, at least in a more interactive ui? Example: If e2fsck starts asking questions like "inode counts don't match for groups (a long list of groups). fix them ", what should I answer? no? that would be nonsense. One of the reasons for these questions are that they are eyebrow-raisers. Say, if your raid1 array got out of sync somehow, a lot of fsck errors will maybe prompt you to look at whether something like that might have happened in the first place. But fsck should be able, as far as it can from the fs metadata, tell the user whether the fs was seriously corrupted by a block device failure (say raid corruption, hd having transfer problems, etc), overwriting of data with garbage, or unclean shutdown / fs-specific kernel bugs. It's the fsck utility that has this data. No power admin will have that kind of knowledge without at least dumping metadata and having a look at it with some specialized tool, or an on-the-spot hacked script to test things out. I had a hardware crash. Or a raid failure. Obviously I don't have recent enough backup, or I really need those last-minute changes back, quickly. Or may system crashed in such a way that some metadata got corrupted. Many ifs. Now please tell me specifically how that knowledge applies to answering particular questions that say ext2fsck or reiserfsck may ask. > for some strange reason no fsck behaves like that. Because most fscks are hacks. They are useful, they mostly do their job, but they are far from full-features tools, and that's the reality. I don't complain. I just say that their functionality isn't optimal, and shouldn't be cited as something that's the way to go, or as something that should be a design goal. They are effects of how much time did the fs-knowing people have to put in them. Cheers, Kuba