Messages in this thread | | | Date | Sat, 2 Jan 1999 23:37:34 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: scary ext2 filesystem question |
| |
Date: Sat, 2 Jan 1999 13:51:33 -0500 From: Raul Miller <rdm@test.legislate.com>
I agree that it would be very nice for fsck to have some kind of logging mechanism.
This is something I've been thinking about. In fact, in the latest e2fsprogs, the problem reporting has been standardized and goes through a single choke point, specifically to make logging easier. My current thinking is to write out a binary log file, which can be interpreted later using an appropriate program. Part of the reason for doing this is so that the binary file can contain a lot of information about the filesystem (possibly including a snapshot of the superblock and block group descriptors), so that people who ask me for help can send me a single file --- since obviously people don't bother to read the e2fsck man page stating what sorts of information I need so that I can help them. Another reason for using a binary log file format is for compactness reasons, since one of the places where these log files might be stored is on the root partition (for all but the root filesystem, obviously).
The problem of where to store the log files is actually an interesting one. The log file you most badly want to have is the one after the catastrophic fsck run, but at that point you might not want to mount the filesystem read/write. So, even if you a standard rc script which stores the log file in RAM disk and then copies the log file from the RAM disk to the disk after the filesystem is mounted read/write, that might not necessarily be the right thing.
So I've been thinking that one of the options might be to store the binary log file on a floppy disk, and that might be the approach that's used when running e2fsck from a rescue disk.
Another design question is how many log files to save? A user might reboot the system several times while trying to fix a mysterious system problem, and so simply saving the last 2 or 3 log files isn't necessarily the right answer either.
So this is actually an interesting problem, and getting the design right so that it works for mere mortals, and not just kernel weanies has some subtle points that have to be gotten right.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |