Hi, > I agree that the important messages from fsck process should be printed > to stdout, and the rest like 'cannot find a valid fs on /dev' belong to > stderr so the user can simply call > > btrfsck > logfile > > and does not miss any messages in the log, while will be informed that > the process cannot proceed for some urgent reason.
That's what I thought as well. I started small, but IMHO, a lot of the output of btrfsck should go to stdout instead of stderr Is there a general agreement on that for a fsck utility, it is normal output, if the filesystem is damaged, and really only stuff which makes the checking stop abnormally should go to stderr? Also, right now there is a very mixed level of verbosity used. I was thinking about adding a '-v' option, and making some of the output conditional on that. The normal enduser will not really care about the number of csum bytes, and as a dev you can still alias the -v. > I think doing the stdout/stderr split properly would need more than > fixing btrfsck.c, it uses code from other .c files, looks like an > overhaul of the logging in the whole codebase. I haven't looked into many other files there, but maybe you are right. I started with btrfsck.c because I think it's a nice entry point. > david Cheers, Dieter -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
